W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [blink-dev] Proposal: Marking HTTP As Non-Secure

From: Jim Manico <jim.manico@owasp.org>
Date: Wed, 7 Jan 2015 07:40:15 -0500
Message-ID: <7241904091323992369@unknownmsgid>
To: Craig Francis <craig.francis@gmail.com>
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>
The experimental IETF Pinning headers in Chrome/Chromium are broken in
several ways, bugs have been submitted and it's being worked on. I can
put you in touch with the bug submitter if you like.

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

> On Jan 7, 2015, at 7:25 AM, Craig Francis <craig.francis@gmail.com> wrote:
>
> 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:40:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC