Bug#752188: xulrunner-29: strict-transport-security implementation too strict

[Juergen]

Package: xulrunner-29
Version: 29.0.1-2
Severity: normal

Dear Maintainer,

to reproduce a particular instance of this problem:

1) remove trust from 'DigiCert High Assurance EV Root CA'

2) add exception for certificate from https://js.stripe.com
   (ultimately signed by above root CA)

3) keep trust on 'AddTrust External CA Root' or add exception for
   certificate from https://www.humblebundle.com

3) open https://www.humblebundle.com/store
   (sourcing js from js.stripe.com)

result:

Site doesn't load, because connection to https://js.stripe.com fails
(it both sends Strict-Transport-Security headers and is present in the
STS preload list).

expected result:

The site should load, because the certificate chain is valid and there
is trust on the particular certificate used by https://js.stripe.com.

workaround:

1) open libxul.so in your favorite hex editor and patch the string
   Strict-Transport-Security

   (or alternatively find another way to hide this header from gecko's
    network layer)

2) disable the use of the builtin STS preload list

3) remove any accumulated sts/* permissions from permissions.sqlite in
   your profile


Discussion:

HSTS isn't new and it's implementation in gecko isn't either, but in
earlier versions the implementation problems weren't noticeable
(probably because fewer sites were using the header).

Arguable HSTS itself is broken because it works around the syptoms
rather than addressing the root issue, namely a broken standard web
site architecture (section 2.3.1.3. of RFC 6797 admits as much), and
a 'No user recourse' policy (section 12.1 of the RFC) is definitelyi
the wrong way to handle security, but this is outside of the scope of
this request.

It could also be argued to be an upstream bug, because an acceptable
solution would be to separate trust and validity inside gecko's
certificate verifier. But the current trust model where trust is
assigned on the CA level and individual trust is the exception is a
conscious design decision that is widely adopted and has become a
business model that is not going to change even (though it is even
more horribly broken from a security perspective).

Since Debian isn't encumbered by or profiting from business decisions
concerning certificate authorities or web advertising and its Social
Contract has users and freedom as high priorities I think it is a
Debian bug to ship the build as is.

The solution could be as simple as disabling the disabling of the
certificate exception processing for sts sites. Since by default
gecko doesn't present an exception dialog for sts sites there is
still no click through vulnerability, i.e. no (easy) user recourse.

Best regards

Juergen Ruehle

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xulrunner-29 depends on:
ii  libasound2                1.0.27.2-4
ii  libatk1.0-0               2.12.0-1
ii  libbz2-1.0                1.0.6-5
ii  libc6                     2.19-1
ii  libcairo2                 1.12.16-2
ii  libdbus-1-3               1.8.4-1
ii  libdbus-glib-1-2          0.102-1
ii  libevent-2.0-5            2.0.21-stable-1
ii  libffi6                   3.1-2
ii  libfontconfig1            2.11.0-5
ii  libfreetype6              2.5.2-1
ii  libgcc1                   1:4.9.0-6
ii  libgdk-pixbuf2.0-0        2.30.7-1
ii  libglib2.0-0              2.40.0-3
ii  libgtk2.0-0               2.24.23-1
ii  libhunspell-1.3-0         1.3.3-1
ii  libnspr4                  2:4.10.6-1
ii  libnss3                   2:3.16.1-1
ii  libpango-1.0-0            1.36.3-1
ii  libsqlite3-0              3.8.4.3-3
ii  libstartup-notification0  0.12-3
ii  libstdc++6                4.9.0-6
ii  libvpx1                   1.3.0-2
ii  libx11-6                  2:1.6.2-2
ii  libxext6                  2:1.3.2-1
ii  libxrender1               1:0.9.8-1
ii  libxt6                    1:1.1.4-1
ii  zlib1g                    1:1.2.8.dfsg-1

xulrunner-29 recommends no packages.

Versions of packages xulrunner-29 suggests:
ii  libcanberra0  0.30-2
pn  libgnomeui-0  <none>

-- no debconf information