Jesse Wilson | 15 May 04:46 2016
Picon
Gravatar

HPKP & different encodings of the same public key

I work on OkHttp, an Android HTTP client that implements HPKP-like certificate pinning. We recently saw a problem where different versions of Android returned different bytes for the ASN.1 encoding of the same certificate. This is bad: the pins don’t match!

The certificate of interest uses a named curve (secp521r1) with ECC. I used der2ascii to view the SPKI ASN.1 bytes.

Older versions of Android (which use BouncyCastle) embed the curve:

SEQUENCE { SEQUENCE { # ecPublicKey OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } SEQUENCE { INTEGER { 1 } SEQUENCE { # prime-field OBJECT_IDENTIFIER { 1.2.840.10045.1.1 } INTEGER { `01ffffffffffffff...` } } SEQUENCE { OCTET_STRING { `01ffffffffffffff...` } OCTET_STRING { `0051953eb9618e1c...` } } OCTET_STRING { `0400c6858e06b704...` } INTEGER { `01ffffffffffffff...` } INTEGER { 1 } } } BIT_STRING { `0004019519de800d...` } }

But new versions of Android (which use Conscrypt/OpenSSL) reference the curve by name:

SEQUENCE { SEQUENCE { # ecPublicKey OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } # secp521r1 OBJECT_IDENTIFIER { 1.3.132.0.35 } } BIT_STRING { `0004019519de800d...` } }

The original certificate embeds the curve.

I believe my problem is that the Java APIs I’m using don’t return raw bytes from the certificate. Instead Java decodes the certificate into a model and re-encodes that when the bytes are requested. The original and roundtripped SPKI bytes are not identical.

Does anyone else do ASN.1 encoding in order to compute a certificate’s pin? Or is it a uniquely Java problem?!

The spec should warn that a single SPKI may have multiple conflicting encodings. I suggest that only encoding in the certificate should be pinned. TLS server administrators should also be careful to not inadvertently re-encode their SPKIs when doing maintenance.

Thanks!

<div><div dir="ltr"><div class="markdown-here-wrapper">
<p>I work on OkHttp, an Android HTTP client that implements HPKP-like certificate pinning. We recently saw a problem where different versions of Android returned different bytes for the ASN.1 encoding of the same certificate. This is bad: the pins don&rsquo;t match!</p>
<p>The certificate of interest uses a named curve (secp521r1) with ECC. I used <a href="https://github.com/google/der-ascii">der2ascii</a> to view the SPKI ASN.1 bytes.</p>
<p>Older versions of Android (which use BouncyCastle) embed the curve:</p>
SEQUENCE {
  SEQUENCE {
    # ecPublicKey
    OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
    SEQUENCE {
      INTEGER { 1 }
      SEQUENCE {
        # prime-field
        OBJECT_IDENTIFIER { 1.2.840.10045.1.1 }
        INTEGER { `01ffffffffffffff...` }
      }
      SEQUENCE {
        OCTET_STRING { `01ffffffffffffff...` }
        OCTET_STRING { `0051953eb9618e1c...` }
      }
      OCTET_STRING { `0400c6858e06b704...` }
      INTEGER { `01ffffffffffffff...` }
      INTEGER { 1 }
    }
  }
  BIT_STRING { `0004019519de800d...` }
}
<p>But new versions of Android (which use Conscrypt/OpenSSL) reference the curve by name:</p>
SEQUENCE {
  SEQUENCE {
    # ecPublicKey
    OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
    # secp521r1
    OBJECT_IDENTIFIER { 1.3.132.0.35 }
  }
  BIT_STRING { `0004019519de800d...` }
}
<p>The original certificate embeds the curve.</p>
<p>I believe my problem is that the Java APIs I&rsquo;m using don&rsquo;t return raw bytes from the certificate. Instead Java decodes the certificate into a model and re-encodes that when the bytes are requested. The original and roundtripped SPKI bytes are not identical.</p>
<p>Does anyone else do ASN.1 encoding in order to compute a certificate&rsquo;s pin? Or is it a uniquely Java problem?!</p>
<p>The spec should warn that a single SPKI may have multiple conflicting encodings. I suggest that only encoding in the certificate should be pinned. TLS server administrators should also be careful to not inadvertently re-encode their SPKIs when doing maintenance.</p>
<p>Thanks!</p>
<div title="MDH:PGRpdj5JIHdvcmsgb24gT2tIdHRwLCBhbiBBbmRyb2lkIEhUVFAgY2xpZW50IHRoYXQgaW1wbGVt
ZW50cyBIUEtQLWxpa2UgY2VydGlmaWNhdGUgcGlubmluZy4gV2UgcmVjZW50bHkgc2F3IGEgcHJv
YmxlbSB3aGVyZSBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgQW5kcm9pZCByZXR1cm5lZCBkaWZmZXJl
bnQgYnl0ZXMgZm9yIHRoZSBBU04uMSBlbmNvZGluZyBvZiB0aGUgc2FtZSBjZXJ0aWZpY2F0ZS4g
VGhpcyBpcyBiYWQ6IHRoZSBwaW5zIGRvbuKAmXQgbWF0Y2ghPGJyPjxicj48L2Rpdj48ZGl2PlRo
ZSBjZXJ0aWZpY2F0ZSBvZiBpbnRlcmVzdCB1c2VzIGEgbmFtZWQgY3VydmUgKHNlY3A1MjFyMSkg
d2l0aCBFQ0MuIEkgdXNlZCBbZGVyMmFzY2lpXSg8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v
Z29vZ2xlL2Rlci1hc2NpaSIgdGFyZ2V0PSJfYmxhbmsiIGRhdGEtc2FmZXJlZGlyZWN0dXJsPSJo
dHRwczovL3d3dy5nb29nbGUuY29tL3VybD9obD1lbiZhbXA7cT1odHRwczovL2dpdGh1Yi5jb20v
Z29vZ2xlL2Rlci1hc2NpaSZhbXA7c291cmNlPWdtYWlsJmFtcDt1c3Q9MTQ2MzM2NTA2MTI1NDAw
MCZhbXA7dXNnPUFGUWpDTkhVYVlRSUFTYXM4cjRUekNVcVVkYXFYRVYzaVEiPmh0dHBzOi8vZ2l0
aHViLjx3YnI+Y29tL2dvb2dsZS9kZXItYXNjaWk8L2E+KSB0byB2aWV3IHRoZSBTUEtJIEFTTi4x
IGJ5dGVzLjxicj48YnI+T2xkZXIgdmVyc2lvbnMgb2YgQW5kcm9pZCAod2hpY2ggdXNlIEJvdW5j
eUNhc3RsZSkgZW1iZWQgdGhlIGN1cnZlOjxicj48YnI+YGBgPGJyPlNFUVVFTkNFIHs8YnI+Jm5i
c3A7IFNFUVVFTkNFIHs8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMgZWNQdWJsaWNLZXk8YnI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IE9CSkVDVF9JREVOVElGSUVSIHsgMS4yLjg0MC4xMDA0NS4yLjEgfTxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsgU0VRVUVOQ0Ugezxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgSU5URUdFUiB7IDEgfTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
U0VRVUVOQ0Ugezxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
IyBwcmltZS1maWVsZDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgT0JKRUNUX0lERU5USUZJRVIgeyAxLjIuODQwLjEwMDQ1LjEuMSB9PGJyPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJTlRFR0VSIHsgYDAxZmZmZmZmZmZmZmZm
ZmYuLi5gIH08YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNFUVVFTkNFIHs8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9DVEVUX1NUUklORyB7IGAwMWZmZmZmZmZmZmZmZmZmLi4u
YCB9PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQ1RFVF9T
VFJJTkcgeyBgMDA1MTk1M2ViOTYxOGUxYy4uLmAgfTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0NURVRfU1RSSU5H
IHsgYDA0MDBjNjg1OGUwNmI3MDQuLi5gIH08YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IElOVEVHRVIgeyBgMDFmZmZmZmZmZmZmZmZmZi4uLmAgfTxicj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgSU5URUdFUiB7IDEgfTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxicj4m
bmJzcDsgfTxicj4mbmJzcDsgQklUX1NUUklORyB7IGAwMDA0MDE5NTE5ZGU4MDBkLi4uYCB9PGJy
Pn08YnI+YGBgPGJyPjxicj48L2Rpdj48ZGl2PkJ1dCBuZXcgdmVyc2lvbnMgb2YgQW5kcm9pZCAo
d2hpY2ggdXNlIENvbnNjcnlwdC9PcGVuU1NMKSByZWZlcmVuY2UgdGhlIGN1cnZlIGJ5IG5hbWU6
PGJyPjxicj5gYGA8YnI+U0VRVUVOQ0Ugezxicj4mbmJzcDsgU0VRVUVOQ0Ugezxicj4mbmJzcDsm
bmJzcDsmbmJzcDsgIyBlY1B1YmxpY0tleTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgT0JKRUNUX0lE
RU5USUZJRVIgeyAxLjIuODQwLjEwMDQ1LjIuMSB9PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAjIHNl
Y3A1MjFyMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgT0JKRUNUX0lERU5USUZJRVIgeyAxLjMuMTMy
LjAuMzUgfTxicj4mbmJzcDsgfTxicj4mbmJzcDsgQklUX1NUUklORyB7IGAwMDA0MDE5NTE5ZGU4
MDBkLi4uYCB9PGJyPn08YnI+YGBgPGJyPjxicj48L2Rpdj48ZGl2PlRoZSBvcmlnaW5hbCBjZXJ0
aWZpY2F0ZSBlbWJlZHMgdGhlIGN1cnZlLjxicj48YnI+PC9kaXY+PGRpdj5JIGJlbGlldmUgbXkg
cHJvYmxlbSBpcyB0aGF0IHRoZSBKYXZhIEFQSXMgSeKAmW0gdXNpbmcgZG9u4oCZdCByZXR1cm4g
cmF3IGJ5dGVzIGZyb20gdGhlIGNlcnRpZmljYXRlLiBJbnN0ZWFkIEphdmEgZGVjb2RlcyB0aGUg
Y2VydGlmaWNhdGUgaW50byBhIG1vZGVsIGFuZCByZS1lbmNvZGVzIHRoYXQgd2hlbiByZXF1ZXN0
ZWQuIFRoZSBvcmlnaW5hbCBhbmQgcm91bmR0cmlwcGVkIFNQS0kgYnl0ZXMgYXJlIG5vdCBpZGVu
dGljYWwuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RG9lcyBhbnlvbmUgZWxzZSBkbyBB
U04uMSBlbmNvZGluZyBpbiBvcmRlciB0byBjb21wdXRlIGEgY2VydGlmaWNhdGXigJlzIHBpbj8g
T3IgaXMgaXQgYSB1bmlxdWVseSBKYXZhIHByb2JsZW0/ITxicj48YnI+VGhlIHNwZWMgc2hvdWxk
IHdhcm4gdGhhdCBhIHNpbmdsZSBTUEtJIG1heSBoYXZlIG11bHRpcGxlIGNvbmZsaWN0aW5nIGVu
Y29kaW5ncy4gSSBzdWdnZXN0IHRoYXQgb25seSBlbmNvZGluZyBpbiB0aGUgY2VydGlmaWNhdGUg
c2hvdWxkIGJlIHBpbm5lZC4gVExTIHNlcnZlciBhZG1pbmlzdHJhdG9ycyBzaG91bGQgYWxzbyBi
ZSBjYXJlZnVsIHRvIG5vdCBpbmFkdmVydGVudGx5IHJlLWVuY29kZSB0aGVpciBTUEtJcyB3aGVu
IGRvaW5nIG1haW50ZW5hbmNlLjxicj48YnI+PC9kaXY+PGRpdj5UaGFua3MhPC9kaXY+">&#8203;</div>
</div></div></div>
RFC Errata System | 8 Apr 13:33 2016

[Errata Verified] RFC7469 (4658)

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=4658

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Jxck <block.rxckin.beats <at> gmail.com>
Date Reported: 2016-04-08
Verified by: Barry Leiba (IESG)

Section: 3.  Reporting Pin Validation Failure

Original Text
-------------
  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z"

Corrected Text
--------------
  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z",

Notes
-----
Missing comma after "effective-expiration-date": "2014-05-01T12:40:50Z" in JSON at              Figure 8: Pin
Validation Failure Report Example

--------------------------------------
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 | 8 Apr 08:40 2016

[Editorial Errata Reported] RFC7469 (4658)

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=4658

--------------------------------------
Type: Editorial
Reported by: Jxck <block.rxckin.beats <at> gmail.com>

Section: 3.  Reportin

Original Text
-------------
  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z"

Corrected Text
--------------
  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z",

Notes
-----
should be comma after "effective-expiration-date": "2014-05-01T12:40:50Z" in JSON at              Figure 8: Pin
Validation Failure Report Example

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

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.

Thanks!
--Wendy

-------- Forwarded Message --------
Subject: HTTPS/HSTS support on www.w3.org servers
Date: Mon, 11 Jan 2016 08:01:05 -1000
From: Coralie Mercier <coralie <at> w3.org>
Organization: W3C

Dear Advisory Committee Representative,
Chairs,

W3C advocates [1] that the Web platform "actively prefer secure
communication." Thanks to recent work in the Web Application Security
Working Group [2] and supporting client implementations, and the
deployment work of the W3C Systems Team, we are now able to provide HTTPS
access to all W3C resources. All W3C documents, including Recommendations,
DTDs, and vocabularies will be available with the authentication,
integrity-protection, and confidentiality HTTPS supports.

HTTPS deployment posed some challenges based on our commitment to preserve
substantial archives of historic material (for which we could not simply
assume that all links were scheme-relative or convert all included content
to HTTPS) and the desire to maintain availability to older clients in the
field that might support only HTTP. Accordingly, our setup makes extensive
use of the Upgrade Insecure Requests [3] spec, but does not force HTTPS on
those who start from HTTP.

Up to now, our main servers have enforced access HTTPS access to protected
resources and HTTP for public resources. Today we upgraded our main
servers to support both HTTP and HTTPS access to public resources. This
change involves the following:

    - Support of the Upgrade-Insecure-Requests HTTP request header [3] for
transparently requesting the upgrade of HTTP requests to HTTPS ones. Note
that you will only get the benefits of this feature if your browser sends
this header.

    - Support of the Strict-Transport-Security HTTP response header (HSTS)
[4] for instructing browsers that they should transparently transform all
HTTP requests to HTTPS ones for all access to the www.w3.org domain. All
recent browsers support this header [5]. It allows to convert a site to
HTTPS without needing to revise the content of all the legacy resources
that may have hard-coded HTTP links. We have been supporting this header
in lists.w3.org and other domains for a long time. This status is cached
in the browser for a given time and will be refreshed each time you browse
an HTTPS link to www.w3.org.

    - We're not planning at this point of time to enforce server
redirection of all HTTP requests to HTTPS ones for public resources. This
is due to avoid breaking older software that can't be upgraded, such as
those in built-in devices. This will be done later at another milestone.
As a consequence, if your browser doesn't send the
Upgrade-Insecure-Requests header, you'll need to browse an HTTPS links
pointing to www.w3.org to get the benefits of using HTTPS on our site.

    - Note that this change has no effect on namespaces. The actual
namespace will continue to use HTTP, even if it is also served through
HTTPS. This applies as well for XMI DTD, Schema, and SGML DTDs resources.

There may be some side-effects you need to be aware of:

    - Infinite loops happening if due to server or proxy configuration
there are hard-coded redirects to an HTTP link after the HSTS header is
cached in your browser. Please send the URL to sysreq <at> w3.org so that we
can fix it.

    - Mixed-content warnings. They will be raised if you're using a
browser that doesn't support Strict-Transport-Security. The solution here
is to update to a more recent browser.

If you have any other issue feel free to mail sysreq <at> w3.org.

Thank you,

Coralie Mercier, Head of W3C Marketing & Communications

[1] http://www.w3.org/2001/tag/doc/web-https
[2] http://www.w3.org/2011/webappsec/
[3] http://www.w3.org/TR/upgrade-insecure-requests/ (Note that the HTTPS:
1 header has been deprecated in favor of Upgrade-Insecure-Requests in the
Editor's draft https://w3c.github.io/webappsec/specs/upgrade/)
[4] http://tools.ietf.org/html/rfc6797
[5]
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Browser_suppor
t

end

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
Gravatar

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


Gmane