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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
