- From: Craig Francis <craig.francis@gmail.com>
- Date: Wed, 7 Jan 2015 12:25:08 +0000
- To: Jim Manico <jim.manico@owasp.org>
- Cc: Jiri Danek <softwaredevjirka@gmail.com>, "mozilla-dev-security@lists.mozilla.org" <mozilla-dev-security@lists.mozilla.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>, blink-dev <blink-dev@chromium.org>
On 7 Jan 2015, at 11:47, Jim Manico <jim.manico@owasp.org> wrote: >> e.g. any feedback for a failed HPKP header? > > You mean the •experimental• HPKP headers that my friends in London > were using on their sites, discovered a few bugs, and submitted that > feedback directly to the Chrome developer over the holidays (who was > stoked for the feedback and is working on fixes), and we'll see those > updates in Chromium soon? Those headers? > > :) Yep, but it is supposedly working in Chrome 39... or at least the pins appear in: chrome://net-internals/#hsts Unfortunately I've got to get back to "real work" rather than getting a second signed certificate to check if the valid pins still block it (perhaps a bit expensive / time consuming for a little side project test). But assuming they do, the feature is kind of implemented already :-) On 7 Jan 2015, at 11:47, Jim Manico <jim.manico@owasp.org> wrote: > Every time a password field is sent over HTTP I cry a little on the > inside, but I will work through it somehow.... •wink• Same here... but the same can be said about the session cookie that is used afterwards on HTTP, or the login form that was loaded over HTTP in the first place (even if the form action is set to a HTTPS URL), or the "AJAX" request that sends the login details over HTTP - because everything has to use JS now :-P Craig
Received on Wednesday, 7 January 2015 12:25:39 UTC