On 14 December 2014 at 18:59, Chris Palmer <pal...@google.com> wrote:

On 14 December 2014 at 19:40, Chris Palmer <pal...@google.com> wrote:

> I would like to see some hypothetical encrypted http:// when a browser
> present a page as if it was over https:// if everything of a secure origin
> and as if it was served over plain http if not. That is, if a future browser
> shows warnings for plain http, so it will show the same warnings for
> encrypted http:// with insecure resources.

On 14 December 2014 at 20:47, Michal Zalewski <lca...@google.com> wrote:

> Then browser should show absolutely no indications of secure origin for
> encrypted http://. The idea is that encrypted http:// experience would be
> equivalent to the current http experience with no indications of security
> and no warnings. However, encrypted http:// with insecure elements will
> start to produce warnings in the same way a future browser will show
> warnings for plain http.

On Sun, Dec 14, 2014 at 11:08 AM, 'Chris Palmer' via Security-dev
<securi...@chromium.org> wrote:
> On Sun, Dec 14, 2014 at 10:53 AM, Igor Bukanov <ig...@mir2.org> wrote:
>
>> I.e. just consider that currently a hosting provider has no option to
>> unconditionally encrypt pages they host for modern browsers as that may
>> break pages of the users. With encrypted http:// they get such option
>> delegating the job of fixing warnings about insecure context to the content
>> producers as it should.
>
>
> I'm sorry; I still don't understand what you mean. Do you mean that you want
> browsers to treat some hypothetical encrypted HTTP protocol as if it were a
> secure origin, but still allow non-secure embedded content in these origins?

However, this „change“ could come with marking HTTP as Non-Secure, but just stating HTTPS as secure is the completely wrong sign and will result in more confusion and loosing any trust in any kind of browser padlocks than before.

Just a proposal:

 

Mark HTTP as Non-Secure (similar to self-signed) e.g. with a red padlock or sth. similar.

Mark HTTPS as Secure (and only secure in favor of encrypted) e.g. with a yellow padlock or sth. similar

Mark HTTPS with Extended Validation (encrypted and validated) as it is with a green padlock or sth. similar

> However, this „change“ could come with
> marking HTTP as Non-Secure, but just stating HTTPS as secure is the
> completely wrong sign and will result in more confusion and loosing any
> trust in any kind of browser padlocks than before.

> Just a proposal:
>
> Mark HTTP as Non-Secure (similar to self-signed) e.g. with a red padlock or
> sth. similar.

> Mark HTTPS as Secure (and only secure in favor of encrypted) e.g. with a
> yellow padlock or sth. similar
> Mark HTTPS with Extended Validation (encrypted and validated) as it is with
> a green padlock or sth. similar

> So indeed an option to declare that despite proper certificates and
> encryption the site should be treated as of insecure origin is needed. This
> way the page will be shown as if it was served as before with plain http
> with no changes in user experience.  But then it cannot be a https site
> since many users still consider that https is enough to assume a secure
> site. Hence the idea of encrypted http:// or something that makes user
> experience with an encrypted page absolutely the same as she has with plain
> http:// down to the browser stripping http:// from the URL.

From an SOP point of view, this is true.
However, it is increasingly less true if you're willing to ignore the (near cataclysmic) SOP failure, as EV gains technical controls such as certificate transparency and pontentially mandatory stronger security settings (e.g. secure ciphersuites in modern TLS, OCSP stapling, etc). Additionally, there are other technical controls (validity periods, key processing) that do offer distinction.

That is, it is not all procedural changes, and UAs can detect and differentiate. While the hope is that these will be able to apply to all sites in the future, any change of this scale takes time.

> If DNS is authentic, then DANE provides stronger assurances than DV or
> EV since the domain operator published the information and the
> veracity does not rely on others like CAs (modulo DBOUND).
>
> Not relying on a CA is a good thing since its usually advantageous to
> minimize trust (for some definition of "trust"). Plus, CAs don't
> really warrant anything, so its not clear what exactly they are
> providing to relying parties (they are providing a a signature for
> money to the applicant).
>
> Open question: do you think the browsers will support a model other
> than the CA Zoo for rooting trust?

Chromium has no plans for this, particularly those based on DNS/DANE, which are empirically less secure and more operationally fraught with peril. I would neither take it as foregone that the CA system cannot improve nor am I confident that any of the known alternatives are either practical or comparable in security to CAs, let alone superior.

On 15 December 2014 at 10:30, Michal Zalewski <lca...@google.com> wrote:

On 12/15/14 2:03 AM, Igor Bukanov wrote:
> Chris' original proposal is a stick. I want to give a site operator also
> a carrot. That can be an option to activate encryption that is not
> visible to the user and *receive* from the browser all reports about
> violations of secure origin policy. This way the operator will know that
> they can activate HTTPS without worsening user experience and have
> information that helps to fix the content.

Hi everyone,

Apologies to those of you who are about to get this more than once, due to the cross-posting. I'd like to get feedback from a wide variety of people: UA developers, web developers, and users. The canonical location for this proposal is: https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure.

Proposal

We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure. We intend to devise and begin deploying a transition plan for Chrome in 2015.

The goal of this proposal is to more clearly display to users that HTTP provides no data security.

Request

We’d like to hear everyone’s thoughts on this proposal, and to discuss with the web community about how different transition plans might serve users.

Background

We all need data communication on the web to be secure (private, authenticated, untampered). When there is no data security, the UA should explicitly display that, so users can make informed decisions about how to interact with an origin.

Roughly speaking, there are three basic transport layer security states for web origins:

• Secure (valid HTTPS, other origins like (*, localhost, *));

• Dubious (valid HTTPS but with mixed passive resources, valid HTTPS with minor TLS errors); and

• Non-secure (broken HTTPS, HTTP).

For more precise definitions of secure and non-secure, see Requirements for Powerful Features and Mixed Content.

We know that active tampering and surveillance attacks, as well as passive surveillance attacks, are not theoretical but are in fact commonplace on the web.

RFC 7258: Pervasive Monitoring Is an Attack

NSA uses Google cookies to pinpoint targets for hacking

Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine

How bad is it to replace adSense code id to ISP's adSense ID on free Internet?

Comcast Wi-Fi serving self-promotional ads via JavaScript injection

Erosion of the moral authority of transparent middleboxes

Transitioning The Web To HTTPS

We know that people do not generally perceive the absence of a warning sign. (See e.g. The Emperor's New Security Indicators.) Yet the only situation in which web browsers are guaranteed not to warn users is precisely when there is no chance of security: when the origin is transported via HTTP. Here are screenshots of the status quo for non-secure domains in Chrome, Safari, Firefox, and Internet Explorer:

Particulars

UA vendors who agree with this proposal should decide how best to phase in the UX changes given the needs of their users and their product design constraints. Generally, we suggest a phased approach to marking non-secure origins as non-secure. For example, a UA vendor might decide that in the medium term, they will represent non-secure origins in the same way that they represent Dubious origins. Then, in the long term, the vendor might decide to represent non-secure origins in the same way that they represent Bad origins.

Ultimately, we can even imagine a long term in which secure origins are so widely deployed that we can leave them unmarked (as HTTP is today), and mark only the rare non-secure origins.

There are several ways vendors might decide to transition from one phase to the next. For example, the transition plan could be time-based:

1. T0 (now): Non-secure origins unmarked

2. T1: Non-secure origins marked as Dubious

3. T2: Non-secure origins marked as Non-secure

4. T3: Secure origins unmarked

Or, vendors might set thresholds based on telemetry that measures the ratios of user interaction with secure origins vs. non-secure. Consider this strawman proposal:

1. Secure > 65%: Non-secure origins marked as Dubious

2. Secure > 75%: Non-secure origins marked as Non-secure

3. Secure > 85%: Secure origins unmarked

The particular thresholds or transition dates are very much up for discussion. Additionally, how to define “ratios of user interaction” is also up for discussion; ideas include the ratio of secure to non-secure page loads, the ratio of secure to non-secure resource loads, or the ratio of total time spent interacting with secure vs. non-secure origins.

We’d love to hear what UA vendors, web developers, and users think. Thanks for reading!

"If someone thinks their users are OK with their website not having integrity/authentication/privacy"

"Presumably these users would still be OK with it after Chrome starts making the situation more obvious."

"Presumably these users would still be OK with it after Chrome starts making the situation more obvious"

On Dec 15, 2014, at 7:10 PM, ferdy.c...@gmail.com wrote:

"If someone thinks their users are OK with their website not having integrity/authentication/privacy"

That is an assumption that doesn't apply to every website. Many websites don't even have authentication.

"Presumably these users would still be OK with it after Chrome starts making the situation more obvious."

Or perhaps it doesn't, and it scares them away. Just like with the cookie bars, where now every user believes all cookies are evil. You assume users are able to make an informed decision based on such warnings, and I doubt that.

"Presumably these users would still be OK with it after Chrome starts making the situation more obvious"

"To respect a user's decision, their decision needs to be an informed one, and it needs to be choice. I don't think there's a reasonable basis to say either of those are the case with users using HTTP in favor of HTTPS:"

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

>Surely you haven't missed the big danger in plain text traffic. That
>traffic gets usuroed and fed into susyems like Xkeyscore for Tailored
>Access Operations (TAO). In layman's terms, adversaries are using the
>information gathered to gain unauthorized access to systems.

>The race to the bottom among CAs is to blame for the quality of
>verification by the CAs.

>With companies like StartCom, Cacert and Mozilla offering free
>certificates, there is no barrier to entry.

>Plus, I don't think a certificate needs to say anything about the
>operator. They need to ensure the server is authenticated. That is, the
>public key bound to the DNS name is authentic.

>As I understand it, phishers try to avoid TLS because they count on the
>plain text channel to avoid all the browser warnings. Peter Gutmann
>discusses this in his Engineering Security book
>(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

>Why green for EV (or why yellow for DV or DANE)? EV does not add any
>technical controls. From a security standpoint, DV and EV are equivalent.

>If DNS is authentic, then DANE provides stronger assurances than DV or EV
>since the domain operator published the information and the veracity does
>not rely on others like CAs (modulo DBOUND).

>Not relying on a CA is a good thing since its usually advantageous to
>minimize trust (for some definition of "trust"). Plus, CAs don¹t really
>warrant anything, so its not clear what exactly they are providing to
>relying parties (they are providing a a signature for money to the
>applicant).

>Open question: do you think the browsers will support a model other than
>the CA Zoo for rooting trust?

On 15 December 2014 at 18:54, Daniel Veditz <dve...@mozilla.com> wrote:

On 16 December 2014 at 01:18, Ryan Sleevi <rsl...@chromium.org> wrote:

On Tue 16 Dec 2014 06:35, Ryan Sleevi <rsl...@chromium.org> writes:

> scheme-relative URLs are awesome, and we should encourage them (over
> explicit http://-schemed URLs)

On Tue, Dec 16, 2014 at 5:59 AM, Sigbjørn Vik <sigb...@opera.com> wrote:

> There is no need to distinguish unsecured from dubiously secured, they
> can just go into the same bucket. There isn't even any need to warn
> users about certificate errors, the UI is just downgraded to insecure,
> as a self-signed site is no less secure than an http site. There are
> technical reasons for the warnings, but those can be bug-fixed. Active
> attacks (e.g. certificate replacement to an invalid one, HSTS failure,
> revoked certificates, ...) might still be hard-blocked, but note that
> this constitutes a fourth state, and the UI is becoming very complicated
> already - there are probably better ways to map such cases into the
> insecure state, but that is a separate discussion.

> BTW, have you explicitly contacted other browser teams?

On 17-Dec-14 08:48, tyl...@google.com wrote:

> Given these roughly 3 distinct scenarios with respect to connection status:
>
> A: The connection is successfully secured. (HTTPS)
> B: No security was attempted. (HTTP)
> C: Securing the connection has failed. (Certificate validation failure)
>
> A few people have said that B and C are roughly identical from a
> security perspective and could be represented as the same state -- in
> both cases no security is provided. I would disagree here. In the case
> of the failed certificate verification, the client has attempted to
> secure the connection and that attempt has failed. In the case of HTTP,
> the client made no indication of a preference for security. While
> scenario B represents the *absence* of security, scenario C represents
> the *failure* of security, and is therefore more troublesome. While we
> want to raise the awareness of scenario B, we shouldn't promote it to
> the severity of scenario C. Doing so conflates two very different cases
> and failure modes; while both represent the absence of verifiable
> transport security, the latter indicates that the user's expressed
> expectation of security has not been met, while the former simply
> reflects the absence of any expectation of security.

> I've
> received many reports from operators large and small indicating
> visible
> losses of revenue due to the nearly-hidden warning Chrome currently
> displays for a SHA-1 cert with a long expiration.

On 16. des. 2014 21:10, 'Chris Palmer' via Security-dev wrote:
> Well, we do have to make sure that the browser does not send cookies
> to an impostor origin. That's (1 reason) why Chrome uses interstitial
> warnings today.

>> BTW, have you explicitly contacted other browser teams?
> This mass mailing is that.

On 17-Dec-14 17:22, 'Adrienne Porter Felt' via Security-dev wrote:
> We plan to continue treating B and C differently. If there is a
> validation failure (C), Chrome will show a full-page interstitial. That
> will not be the case for HTTP (B). They will look the same in the URL
> bar because they are both insecure but the overall experience will be
> quite different.

> On Wed, Dec 17, 2014 at 3:52 AM, Sigbjørn Vik <sigb...@opera.com

>     give no preference for
>     security. Any such preference is a server preference. The same holds for
>     clicking links, the user has no expectation of where he will be taken.
>     For bookmarks, or cases where the user explicitly types 'https://', the
>     user might have an expectation of security. If he does, and the security
>     level of the page indicates either B or C, he should immediately be
>     alerted anyway. If you think this indicates an explicit preference for
>     security, then the browser could warn similar to an active attack in
>     these cases.
>
>     But my main point against this is still that you need an entire
>     paragraph to explain the difference, to people who already know the
>     background. A user wants to know if he is secure or not, not if his

>     way and replaced by a http
>     MiTM (status B, really bad), or if 'facebook.com

>     exposed (status C, pretty bad). Most users wouldn't understand the
>     difference. I consider it arrogant trying to force users to understand
>     the difference, most users just want to go to facebook, not get a
>     lecture on internet safety. I consider it harmful to try to display the
>     difference, as the more states we have in the UI, the more users have to
>     learn, which means they will remember less, and the states become less
>     meaningful. Keep it simple, and keep to user expectations, not
>     implementation details.
>
>     As a consumer buying bread, you want to know if the bread is safe to eat
>     or not. Whether the farmer tried to control pesticide usage and failed,
>     or he didn't try to control it, makes little difference. Professional
>     health and safety inspectors (akin to browser and web developers) are
>     about the only ones who care.
>
>     > I've
>     > received many reports from operators large and small indicating
>     > visible
>     > losses of revenue due to the nearly-hidden warning Chrome currently
>     > displays for a SHA-1 cert with a long expiration.
>
>     Are you able to share more details on this?
>
>     --
>     Sigbjørn Vik
>     Opera Software
>

> To unsubscribe from this group and stop receiving emails from it, send

On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <sigb...@opera.com> wrote:
> I respectfully, but strongly, disagree :) If you want to separate the
> states, I'd say that C is better than B. C has *some* security, B has
> *none*.

On 17-Dec-14 18:17, Anne van Kesteren wrote:
> On Wed, Dec 17, 2014 at 12:52 PM, Sigbjørn Vik <sigb...@opera.com> wrote:
>> I respectfully, but strongly, disagree :) If you want to separate the
>> states, I'd say that C is better than B. C has *some* security, B has
>> *none*.
>
> You would advocate not blocking on certificate failures
> and just hand
> over credentials to network attackers?

> What would happen exactly when
> you visit e.g. google.com from the airport (connected to something
> with a shitty captive portal)?

This is a pretty interesting use case. When you connect at the airport, the typical first thing that happens is you get a warning saying that the site you want to connect to has the wrong certificate (you went to pogoda.yandex..ru but the certtificate is for airport.logins.aero, or 1.1.1.1).

--
Charles McCathie Nevile - web standards - CTO Office, Yandex

Charles McCathie Nevile - web standards - CTO Office, Yandex

cha...@yandex-team.ru - - - Find more at http://yandex.com

Inline

On Dec 18, 2014 1:07 AM, <cha...@yandex-team.ru> wrote:
>
>  
>  
> 18.12.2014, 01:27, "software...@gmail.com" <software...@gmail.com>:
>>
>> On Wednesday, December 17, 2014 7:44:59 PM UTC+1, cha...@yandex-team.ru wrote:
>>>
>>> This is a pretty interesting use case. When you connect at the airport, the typical first thing that happens is you get a warning saying that the site you want to connect to has the wrong certificate (you went to pogoda.yandex.ru but the certtificate is for airport.logins.aero, or 1.1.1.1).
>>> --
>>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>>
>>
>> 511 Network Authentication Required?
>>
>> There is http://tools.ietf.org/html/rfc6585#section-6 for that. Chromium bug is https://code.google.com/p/chromium/issues/detail?id=114929 , Firefox has their own as well. As far as I know this only works for HTTP connections. There really is no reasonable way how the airport can step into an HTTPS connection and demand authentication without causing a certificate error.
>
>  
> There is a certificate error. The point is that since it is expected behaviour, I get trained to say "yeah, whatever" so I can pay for the connection I need. Despite the fact that it is very difficult to be *sure* that the error is not actually a real problem.
>  
> I'd love to see a better situation relying on a proper standard.
>  
> But in general I don't.
>  

I'm not sure if it's terribly germane to the HTTP-being-indicated-as-not-secure to rathole too much on the ways that HTTPS can be messed with, but I will simply note that the Chrome Security Enamel team are working on ways to better detect and manage this.

While we can wish for better standards, this is an area where standards compliant devices take years to become even remotely ubiquitous. As such, a heuristic based approach on the way the world is, at least with respective to captive portals that actively try to disrupt and compromise users' connections.

>>
>> There is experimantal https://tools.ietf.org/rfc/rfc2521.txt which suggests an ICMP packet "Need Authorization", but as I said, it is experimantal. Am I missing something?
>>  
>> This gradual roll out of the UI hints that is being proposed now would help shift attention to such problems. The problems won't be solved until we get to a state we (actually, you ;) truly _need_ to be solving them.
>
>  
> Sure. But this turns out to be a case where right now there is a problem, and instead of *solving* it it seems that "the world" (or at least the parts I see, which is quite a lot by geography) is instead finding a quick workaround that gets them where they were going - at the cost of learning to ignore a potentially serious problem.
>  
> On the whole I think this discussion is valuable, and the proposal makes sense. But I have concerns about whether we really understand the things that are going to change and the implications, so use cases like this are important to find and make sure we understand.
>  
> cheers
>  
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com
>  

As noted elsewhere, we aren't trying to boil the ocean, and though I certainly accept the concerns are valid (and, as mentioned above, are already being independently worked on), I think we should be careful how much we fixate on these issues versus considering the broader philosophical issues this proposal is bringing forward.

There are certainly awful things in the world of HTTPS, on a variety of fronts. And yet, despite those warts, we would be misleading ourselves and others to think that insecure transports such as HTTP - ones actively disrupted for commercial gain, "value" adding, or malicious havoc and ones that are passively monitored on widespread, pervasive scale  - represent the desirable state of where we want to be or go.

I think the end goal is more robust - we want a world where users are not only safe by default, but they expect that, and can understand what makes them unsafe. Though some of these may be outside our ken as UAs - for example, we have limited ability to know you're running a three year old version of phpBB that is owned harder than Sony Pictures and has more remote exploits than msasn1.dll - there are things we do know and should communicate. One of them is that the assumption many users have - that their messages are shared only between them and the server - is not true unless the server operator is conscientious.

On 12/18/2014 04:07 AM, cha...@yandex-team.ru wrote:
> There is a certificate error. The point is that since it is expected behaviour,
> I get trained to say "yeah, whatever" so I can pay for the connection I need.
> Despite the fact that it is very difficult to be *sure* that the error is not
> actually a real problem.
> I'd love to see a better situation relying on a proper standard.
> But in general I don't.

On Thu, Dec 18, 2014 at 9:14 AM, Gervase Markham <ge...@mozilla.org> wrote:

> I think this is a good idea - in fact, it's essential if we are to make
> secure the 'new normal'.

> I agree that a phased transition plan based on telemetry thresholds is
> the right thing. This is a collective action problem ("Chrome tells me
> this site is insecure, but Firefox is fine - so I'll use Firefox") and
> so it would be awesome if we could get cross-browser agreement on what
> the thresholds were and how they were measured.

> I wonder whether we could make a start by marking non-secure origins in
> a neutral way, as a step forward from not marking them at all. Straw-man
> proposal for Firefox: replace the current greyed-out globe which appears
> where the lock otherwise is with a black eye icon. When clicked, instead
> of saying:
>
> "This website does not supply identity information.
>
> Your connection to this website is not encrypted."
>
> it has a larger eye icon, and says something like:
>
> "This web page was transferred over a non-secure connection, which means
> that the information could have been (was probably?!) intercepted and
> read by a third party while in transit."
>
> There are many degrees of this; let's start moving this way.

On Thu, Dec 18, 2014 at 9:52 AM, jstriegel via blink-dev
<blin...@chromium.org> wrote:

> I'd like to propose consideration of a fourth category:
> Personal Devices (home routers, printers, IoT, raspberry pis in classrooms, refrigerators):
>  - cannot, by nature, participate in DNS and CA systems
>  - likely on private network block
>  - user is the owner of the service, hence can trust self rather than CA
>
> Suggested use:
>  - IoT devices generate unique, self-signed cert
>  - Friendlier interstitial (Ie. "Is this a device you recognize?") for self-signed connections on *.local, 192.168.*, 10.*, or on same local network as browser.
>  - user approves use on first https connection
>  - browser remembers (device is promoted to "secure" status)
>
> A lot of IoT use cases could benefit from direct connection (not requiring a cloud service as secure data proxy), but this currently gives the scariest of Chrome warnings. This is probably why the average home router or firewall is administered over http.

On Thu, Dec 18, 2014 at 12:12 PM, Monica Chew <m...@mozilla.com> wrote:

> I support the goal of this project, but I'm not sure how we can get to a
> point where showing warning indicators makes sense. It seems that about 67%
> of pageviews on the Firefox beta channel are http, not https. How are
> Chrome's numbers?

> Security warnings are often overused and therefore ignored [1]; it's even
> worse to provide a warning for something that's not actionable. I think we'd
> have to see very low plaintext rates (< 1%) in order not to habituate users
> into ignoring a plaintext warning indicator.

> Lots of site operators don't support HTTPS, in fact some of them (e.g.,
> https://nytimes.com and https://monica-at-mozilla.blogspot.com, which is out
> of my control) redirect to plaintext in order to avoid mixed content
> warnings. I don't think that user agents provided the right incentives in
> this case, and showing a warning 100% of the time to a NYTimes user seems
> like a losing battle.

> Why not shift the onus from the user to the site operators?

On Thu, Dec 18, 2014 at 12:27 PM, Chris Palmer <pal...@google.com> wrote:

On Thu, Dec 18, 2014 at 1:18 PM, Monica Chew <m...@mozilla.com> wrote:

> Thanks for the numbers. That's a significant gap (58% vs 33%). Do you have
> any idea why this might be the case?

> I understand the desire here, but a passive indicator is not going to change
> the status quo if it's shown 42% of the time (or 67% of the time, in
> Firefox's case).

> Other passive indicators (e.g., Prop 65 warnings if you
> live in California, or compiler warnings that aren't failures) haven't
> succeeded in changing the status quo.

> Again, what's the action that typical
> users are going to take when they see a passive indicator?

On 12/18/2014 12:14 PM, Gervase Markham wrote:
> I wonder whether we could make a start by marking non-secure origins in
> a neutral way, as a step forward from not marking them at all. Straw-man
> proposal for Firefox: replace the current greyed-out globe which appears
> where the lock otherwise is with a black eye icon. When clicked, instead
> of saying:
>
> "This website does not supply identity information.
>
> Your connection to this website is not encrypted."
>
> it has a larger eye icon, and says something like:
>
> "This web page was transferred over a non-secure connection, which means
> that the information could have been (was probably?!) intercepted and
> read by a third party while in transit."

This web page was transferred over a non-secure connection, which means

> Four proposed fine-tunings:
>
>  A) i don't think we should remove "This website does not supply
> identity information" -- but maybe replace it with "The identity of this
> site is unconfirmed" or "The true identity of this site is unknown"

On Thu, Dec 18, 2014 at 2:22 PM, Jeffrey Walton <nolo...@gmail.com> wrote:

>>  A) i don't think we should remove "This website does not supply
>> identity information" -- but maybe replace it with "The identity of this
>> site is unconfirmed" or "The true identity of this site is unknown"
>
> None of them are correct when an interception proxy is involved. All
> of them lead to a false sense of security.
>
> Given the degree to which standard bodies accommodate (promote?)
> interception, UA's should probably steer clear of making any
> statements like that if accuracy is a goal.

I'm sorry, this isn't how HTTPS works and isn't accurate, unless you have explicitly installed the routers cert as a CA cert. If you have, then you're not really an unwitting user (and it is quite hard to do this).

Of course, everything you said is true for insecure HTTP. Which is why this proposal is about reflecting that truth to the user.

On 12/18/2014 05:55 PM, Michael Martinez wrote:
> No it doesn't need a certificate.  A MITM can be executed through a
> compromised or rogue router.  It's simple enough to set up a public
> network in  well-known wifi hotspots and attract unwitting users. Then
> the HTTPS doesn't protect anyone's transmission from anything as the
> router forms the other end of the secure connection and initiates its
> own secure connection with the user's intended destination (either the
> site they are trying to get to or whatever site the bad guys want them
> to visit).

On Thu, Dec 18, 2014 at 3:39 PM, Michael Martinez
<michael...@xenite.org> wrote:

> You're assuming people don't connect to open wifi hotspots where rogue
> routers can be set up by anyone.  If thieves are willing to build fake ATM
> machines and distribute them to shopping centers across a large geographical
> area then they will certainly go to the same lengths to distribute rogue
> routers.

On 12/18/2014 6:49 PM, Chris Palmer wrote:
> On Thu, Dec 18, 2014 at 3:39 PM, Michael Martinez
> <michael...@xenite.org> wrote:
>
>> You're assuming people don't connect to open wifi hotspots where rogue
>> routers can be set up by anyone.  If thieves are willing to build fake ATM
>> machines and distribute them to shopping centers across a large geographical
>> area then they will certainly go to the same lengths to distribute rogue
>> routers.
> Indeed, there are many rogue wifi hotspots, and indeed many rogue
> routers at ISPs (it's definitely not just "last mile" routing that we
> need to be concerned about).
>
> The part you're missing is that the man-in-the-middle attacker needs
> to present a certificate for the server, say mail.google.com, that was
> issued by a certification authority *that the client trusts*. Not just
> any certificate for mail.google.com will do.

> Now, this is not an insurmountable obstacle to the attacker. But it is
> non-trivial: the CAs that clients trust are trying hard not to
> mis-issue certificates. And, we are working to make it even more
> difficult for attackers, such as with our Certificate Transparency and
> public key pinning efforts.
>
> Before arguing against HTTPS, you should make sure you know how it works.

On 12/18/2014 06:46 PM, Michael Martinez wrote:
> No, what I am saying is that you can bypass the certificate for a MITM
> attack via a new technique that was published earlier this year.

> If you
> compromise someone else's router you can control it from your own nearby
> router.  The compromised router with the valid certificate sends the
> user through whatever gateway you specify.

Google, the great champion of HTTPS/SSL, cannot prevent yet more man-in-the-middle attacks against its users: http://www.theregister.co.uk/2014/11/21/hackers_snaffling_smartphone_secrets_with_redirection_attack/

If your company is serious about using HTTPS it has to do it right (not that it will matter, but don't throw your money away on bad implementation).  http://www.darkreading.com/endpoint/the-week-when-attackers-started-winning-the-war-on-trust-/a/d-id/1317657

On 12/18/2014 6:57 PM, Daniel Kahn Gillmor wrote:
> On 12/18/2014 06:46 PM, Michael Martinez wrote:
>> No, what I am saying is that you can bypass the certificate for a MITM
>> attack via a new technique that was published earlier this year.
> Links, please.

>
>> If you
>> compromise someone else's router you can control it from your own nearby
>> router.  The compromised router with the valid certificate sends the
>> user through whatever gateway you specify.
> You seem to be saying now that the attacker does need a valid
> certificate; earlier you claimed no certificate was needed.

> The fact that HTTPS is not 100% perfect does not mean that HTTP is
> somehow secure.

> On Dec 18, 2014, at 7:08 PM, Michael Martinez <michael...@xenite.org> wrote:
>
> On 12/18/2014 6:57 PM, Daniel Kahn Gillmor wrote:
>> On 12/18/2014 06:46 PM, Michael Martinez wrote:
>>> No, what I am saying is that you can bypass the certificate for a MITM
>>> attack via a new technique that was published earlier this year.
>> Links, please.
> I'm not going to sit here and do the research that you should already be doing for yourself, but here is one link that explains how some smart phone apps were compromised.  It's disturbing to see that people working on security protocols are not aware of articles that have appeared on security blogs, in news media, and on university Websites.
>
> A Study of SSL Proxy Attacks on Android and iOS Mobile Applications
> http://harvey.binghamton.edu/~ychen/CCNC2014_SSL_Attacks.pdf
>
> This is only one example.

>>
>>> If you
>>> compromise someone else's router you can control it from your own nearby
>>> router.  The compromised router with the valid certificate sends the
>>> user through whatever gateway you specify.
>> You seem to be saying now that the attacker does need a valid
>> certificate; earlier you claimed no certificate was needed.
> If you compromise a legitimate router you just hide behind the legitimate router and send people wherever you want.  What's one or two more hops even if you're only passing them through a gateway they know nothing about?  One recent study followed traffic on compromised routers that did nothing.  The researchers suggested that it may have been an early stage botnet either in testing or buildout.
>> The fact that HTTPS is not 100% perfect does not mean that HTTP is
>> somehow secure.
> HTTP doesn't need to be secure.  Explain to me why I should have to have connect to an HTTPS server just to read the news or a blog?  If I am not passing any information to the Website, why does it have to be hosted on HTTPS?  That is not trivial for the average Webmaster.
>
> I'm not just concerned about HTTPS attacks.  I'm also concerned about wasted effort being spent on unnecessary security because of Google's fear-mongering.  I get why they are doing this.  They were hurt in the public image by the Edward Snowden scandal.  But they sure don't mind telling everyone they have no reasonable expectation of privacy when their services are involved.
>
> BTW -- as you do your due diligence in these matters, look also for information on how YouTube videos can be used to compromise users' computers.  Gosh, that's an HTTPS Website, isn't it?  I feel safer already.
>
> Complexity that serves no useful purpose represents no improvement on the status quo.  Google and those who stand with it on these "privacy" issues need to make a much better case for coercing millions of Websites into using HTTPS.
>
> Browser developers do not need to participate in this public shaming game.
>
> I will leave off on this discussion at this point as it is clear to me I am better informed about what is happening than some, and I really am not going to be drawn into to sharing link after link in order to play a stalling game.
>
> Some of you guys have already made up your minds on this without doing proper research.  But you clearly haven't stopped to think about what a burden you will create for millions of Website owners who have no idea of how to support this insane initiative.  And that will just make them more dependent on self-serving solution providers like Google.
>
> Don't do this.  Please do NOT screw up the web with this nonsense.

On Thu, Dec 18, 2014 at 4:08 PM, Michael Martinez
<michael...@xenite.org> wrote:

> A Study of SSL Proxy Attacks on Android and iOS Mobile Applications
> http://harvey.binghamton.edu/~ychen/CCNC2014_SSL_Attacks.pdf

On 12/18/2014 7:14 PM, Donald Stufft wrote:
> I'm not going to sit here and do the research that you should already be doing for yourself, but here is one link that explains how some smart phone apps were compromised.  It's disturbing to see that people working on security protocols are not aware of articles that have appeared on security blogs, in news media, and on university Websites.
>
> A Study of SSL Proxy Attacks on Android and iOS Mobile Applications
> http://harvey.binghamton.edu/~ychen/CCNC2014_SSL_Attacks.pdf
>
> This is only one example.
> A skim of this shows that this is about mobile apps not correctly verifying TLS and has nothing to do with whether TLS as a protocol is broken. Probably you should learn how TLS actually works and read the papers you are linking before making extraordinary claims.

On 12/18/2014 7:17 PM, Chris Palmer wrote:
> On Thu, Dec 18, 2014 at 4:08 PM, Michael Martinez
> <michael...@xenite.org> wrote:
>
>> A Study of SSL Proxy Attacks on Android and iOS Mobile Applications
>> http://harvey.binghamton.edu/~ychen/CCNC2014_SSL_Attacks.pdf
> That paper describes bugs in the certificate validation procedures *of
> specific clients*. (Note that the authors call out the fact that the
> clients in question are *not* browsers.)

>
>
> Thanks for the numbers. That's a significant gap (58% vs 33%). Do you have
> any idea why this might be the case?

>
>
> I understand the desire here, but a passive indicator is not going to change
> the status quo if it's shown 42% of the time (or 67% of the time, in

> live in California, or compiler warnings that aren't failures) haven't

> users are going to take when they see a passive indicator?
>

On 12/18/2014 7:54 PM, Donald Stufft wrote:
> Agreed.  The paper only looks at mobile apps, of which only some were found to be compromised.  But those of you responding with objections are completely missing the point.  Google wants everyone to switch over to using secure protocols and the execution will not only never be perfect, the hackers already have sufficient information about how the SYSTEM works that they are seeking other ways to bypass the security.  All they have to do is insert a rogue proxy somewhere in the middle, and they can do that in a lot of different ways.
> You’re missing a step here, “All they have to do is insert a rogue proxy somewhere in the middle AND either get a certificate incorrectly issued to them (really hard to do) or the client software in question needs to not properly implement TLS. In this as far as anyone is currently aware Chrome (and Mozilla, and all the major browsers) are currently implementing TLS correctly so unless someone finds a bug there (which would be promptly fixed) and the CA vendors are not currently mis-issuing certificates.

> Indicating that the connection isn’t secure isn’t forcing everyone to use HTTPS. Disabling HTTP access altogether would do that, but nobody is suggesting that. All this proposal really does is have the user agents be honest and ethically inform their users of the properties of their current connection.

On Thu, Dec 18, 2014 at 8:30 PM, Chris Bentzel <cben...@chromium.org> wrote:
> On Thu, Dec 18, 2014 at 4:18 PM, Monica Chew <m...@mozilla.com> wrote:
>> On Thu, Dec 18, 2014 at 12:27 PM, Chris Palmer <pal...@google.com> wrote:
>>>
>>> On Thu, Dec 18, 2014 at 12:12 PM, Monica Chew <m...@mozilla.com> wrote:
>>>
>>> > I support the goal of this project, but I'm not sure how we can get to a
>>> > point where showing warning indicators makes sense. It seems that about
>>> > 67%
>>> > of pageviews on the Firefox beta channel are http, not https. How are
>>> > Chrome's numbers?
>>>
>>> Currently, roughly 58% of top-level navigations in Chrome are HTTPS.
>>
>>
>> Thanks for the numbers. That's a significant gap (58% vs 33%). Do you have
>> any idea why this might be the case?
>
> It's possible this is due to Firefox not counting same-frame
> navigations (fragment change, pushState) as top-level navigations.

On Thu, Dec 18, 2014 at 6:33 PM, Monica Chew <m...@mozilla.com> wrote:

> I'm making the argument that most people will ignore passive indicators, the
> ones who notice it will be frustrated because it's not actionable (other
> than not visiting the site),

> especially at the non-HTTPS traffic rates we
> are seeing, and that there are probably better ways to put pressure on site
> operators. Sorry if that wasn't clear.

While the transmission of data is indeed an active concern, I believe you underestimate the risks and attacks posed by the mere passive receipt of data.

This could be the viewing of a video that is contrarian to local authorities. It could be reading an article on reproductive health or religious beliefs that are contrary to local norms. Revealing this information could get you in "trouble", for some definition of trouble.

You could be reading the news and using the information as part of your investment and long-term planning. An attacker who can modify this can convince you that the sky is falling - or that there is a grand new investment opportunity.

You could be reading a blog, but which an attacker changes the content to suggest the blogger is endorsing or holding views contrary to what they really hold.

You could be just browsing the web, and a pervasive passive monitor could use this to build a profile of you, to track your related experiences on a variety of sites, to cross-reference your interactions, and then declare you a "threat" for otherwise benign interactions.

You could be reading a website supported by advertising, but that advertising might be rewritten to credit the attacker, rather than the site you're reading. Over time, the site you're reading may need to shut down, because all of their revenue has been stolen by attackers.

The reality is that the confidentiality, integrity, and authenticity of the content matters just as much for the receiver as it does the sender. This is not merely being done solely for privacy grounds - but even if it was, that goal would only be achievable if the response was as protected as the request.

The other reality is that the mere act of an HTTP Request leaks a lot of ambient state that is not intuitively associable with a user's action or intent. Further, when you consider cookies, any proposal to do it heuristically on the request devolves quickly into doing it for (effectively) every request. This proposal not only simplifies what is expected of developers AND vastly simplifies what is messaged to users, but it can provide real protection.

However, even on top of all that, this proposal is not explicitly geared towards any of what I said - even though it is all true. It is about ensuring user agents do not mislead users about the state of the connection, as they have for so long, implying through omission that their connections are secure or private. For whatever attacks there may be on HTTPS, whether implementation to operation, whatever attacks there may be on the content, such as XSS or CSRF, it is unquestionable that HTTP is an insecure transport that offers zero confidentiality, zero integrity, and zero authenticity, and user agents should appropriately reflect that hard truth.

> If users are on sites that are transmitting any personally identifiable information, such as geo-location information, name, address, telephone, etc., to a non-secure site that the user should definitely be informed.  However there are also plenty of cases where a site may not employ HTTPS that the user does not necessarily need to be notified about.  Good examples of this may be news sites, blogs, etc., where a user does not need to login or provide any other information.

---

Donald Stufft

PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Fri, Dec 19, 2014 at 1:34 PM, Monica Chew <m...@mozilla.com> wrote:

Why not shift the onus from the user to the site operators? I would love to see a "wall of shame" for the Alexa top 1M sites that don't support HTTPS,

Just to follow up on this, from section 5.4 of http://randomwalker.info/publications/cookie-surveillance-v2.pdf, 87% of the sites from Alexa top 500 serve HTTP by default, and 66% of them don't serve HTTPS at all, as measured by using HTTPS-Everywhere.

Thanks,
Monica

 

On 12/19/2014 8:33 PM, Donald Stufft wrote:
> So how is marking some Websites as "non-secure" (they all are) improving the situation?  Shaming Website owners for not using encrypted connections, especially when your only concern is that you don't want some random stranger to see that you are reading a blog, is not acceptable.
> I think you’re fundamentally confused, I do not believe that anyone who is making this proposal is trying to force site operators to use HTTPS.

On Fri, Dec 19, 2014 at 7:32 PM, Michael Martinez <michael...@xenite.org> wrote:

On 12/19/2014 8:33 PM, Donald Stufft wrote:

So how is marking some Websites as "non-secure" (they all are) improving the situation?  Shaming Website owners for not using encrypted connections, especially when your only concern is that you don't want some random stranger to see that you are reading a blog, is not acceptable.
I think you’re fundamentally confused, I do not believe that anyone who is making this proposal is trying to force site operators to use HTTPS.

Then I suggest you go back and reread the other posts from people who have said exactly that.

It is precisely this kind of inattention to what is actually being said that keeps resetting this conversation.

I am very ill right now and I don't have the energy for further discussion.  I hope that the people who need to consider these things see past the needless nit-pickery and think about the big picture.  You won't be able to undo the damage this proposal will do, if it is carried out, even if that turns out to be less than some of us fear.

"We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure."

"(a) Users are currently habituated to treat non-secure transport as 

OK. The status quo is terrible. 

(b) What Peter Kasting said: we propose a passive indicator, not a 
pop-up or interstitial. "

On Dec 18, 2014 10:12 PM, "Monica Chew" <m...@mozilla.com> wrote:

> Security warnings are often overused and therefore ignored [1]; it's even
> worse to provide a warning for something that's not actionable. I think
> we'd have to see very low plaintext rates (< 1%) in order not to habituate
> users into ignoring a plaintext warning indicator.

If the indicator is initially unobtrusive (e.g. in Firefox changing the light gray globe to a darker gray eye) and the doorhanger just states the truth about the lack of confidentiality, integrity and authenticity, positive effects can be had even if the bulk of users ignore it. As long as it makes site operators are uneasy with users maybe realizing the truth about http being insecure as opposed to neutral, this may well lead to side operators choosing to switch to https. That is, this initiative can be a success even if most users ignore it, because most users don't need to be the audience for them to benefit. The audience needs to be site operators and a subset of users that the site operators don't want to alienate.

> People who use their work networks to browse the Web have to accept that
> their employers have a legal right to monitor their activity; if they
> are in a public wifi spot and they connect to the wrong router, they are
> hosed.  Even in a secure connection the employers and bad guys can still
> see where the packets are going if they control access point.

> I don't care how much TLS is improved from this point on (because in the
> end I have to trust my credit card data with the idiot storing that data
> in an unencrypted database that isn't properly firewalled).

> I do care
> about whether the security community joins Google's campaign to convert
> the Web to using a protocol that is totally inappropriate in situations
> where no secure data exchange is required.  Sure, I get that a Website
> login can be sniffed in a public wifi spot; that is why hackers use
> methods to bypass TLS protections.
>
> I ask that if you want to respond to me, then respond to my questions.
> Please don't bring up TLS and Chrome again.  That isn't what this is about.
>
> Website owners will want to know why users should not trust their sites
> when they don't ask for or require credit card information. This
> proposal is part of Google's long-term campaign to change the entire
> Web.  They have yet to explain why the Web needs to get off of HTTP. The
> fact a small percentage of people don't want anyone to know what sites
> they browse isn't good enough.

>> Indicating that the connection isn’t secure isn’t forcing everyone to
>> use HTTPS. Disabling HTTP access altogether would do that, but nobody
>> is suggesting that.

>> All this proposal really does is have the user
>> agents be honest and ethically inform their users of the properties of
>> their current connection.

> It's an act of intimidation.  You may not see it that way but many of
> the Website owners who have to deal with the implications of lost user
> trust DO.  And how the victims of intimidation feel is very important in
> a discussion of the tools being used.

> There is nothing ethical in Google's proposal.

> It is a dirty,
> underhanded propaganda tactic that sidesteps a fair and open public
> discussion with the people who will be most affected.  They are enticing
> the security community into supporting a sweeping change without fully
> explaining WHY they want it or why it should even be expected to provide
> any benefit.

> Earlier this year Google disclosed that it was giving a slight boost in
> its search results to Websites that use HTTPS.  Many marketers
> immediately began discussing the implications of this algorithmic change
> but they don't know how to do the math.

> If the same boost is applied to every site then the signal washes out in
> the mix.  But it is a carrot that Google has dangled in front of the
> donkeys.

> They love to dangle carrots.  See those carrots for what they are.

> DEMAND A FULL EXPLANATION FROM GOOGLE for why this proposal should be
> adopted.

On 22-Dec-14 13:05, Anne van Kesteren wrote:
> On Wed, Dec 17, 2014 at 6:50 PM, Sigbjørn Vik <sigb...@opera.com> wrote:
>>> What would happen exactly when
>>> you visit e.g. google.com from the airport (connected to something
>>> with a shitty captive portal)?
>>
>> Assuming interstitials were replaced with cache separation:
>>
>> The browser would detect that this isn't the same secure google you
>> talked to yesterday, and not share any data you got from google
>> yesterday with the captive portal. Once you reconnect to the authentic
>> google, the browser would use the first set of data again.
>
> How would the user distinguish this case from cookies expiring,
> getting lost for some reason,

> or the monthly two-factor authentication
> dance? This sounds very dangerous.

> What if google.com uses certificate pinning?

On 24 Dec 2014 03:53, "Austin William Wright" <a...@bzfx.net> wrote:
>
> My interest in this is I study and design HTTP servers and content management systems professionally, including HTTPS website deployment for a Certificate Authority.
>
> I would first like to note that there is a very high cost to implementing HTTPS. For individuals, they have to verify ownership of a domain name and/or business entity, install a TLS certificate, and then figure out why their embeds and scripts stopped working. For enterprise, we have to figure out how to mint and revoke large numbers of certificates, and store large numbers of private keys securely (a database with ten thousand private TLS keys is a very precious target indeed!).
>
> If someone uses HTTPS, they do so because they anticipate they need the security. Especially considering someone took on a not-insignificant cost to ensure that their users would have that security. The request for security means something!

No, the request for a resource means something. Security is about the quality of service in delivering said thing.

> HTTP could mean, simply, "I don't care about security".

Then user agents should be free to act on behalf of users to write off correspondents who do not value the user enough to protect the message in transit.

You're making claims about what UA's must do from the perspective of servers; this is a clear agency problem misunderstanding.

We're the user's agent, not the publisher's.

> A TLS failure means "Security is _required_ by the other party, but couldn't be set up and verified. Abort! Abort!"
>
> Purporting that plaintext and HTTPS failure is the same would be conditioning users to be less worried about HTTPS failures, where there's a known _requirement_ for confidentiality.

The UA could develop different (but also scary) UI for these conditions.

Regardless, we have done a poor job communicating the effective system model (that content is not tamper-evidentwhen served over HTTP). Steps to make this clearer aren't the same thing as throwing all distinction overboard.

> There may be some value in saying "as with many network requests, request/submission is being sent in the clear. Anyone on your network will be able to read this!". But big scary warnings are most certainly bad. No matter what, before I claim anything for sure, I would like to see a double-blind study, and not change for the sake of change.

This sort of argument might have worked in '12. Apologies, but you're dreadfully late.

>> Particulars
>>
>>
>> UA vendors who agree with this proposal should decide how best to phase in the UX changes given the needs of their users and their product design constraints. Generally, we suggest a phased approach to marking non-secure origins as non-secure. For example, a UA vendor might decide that in the medium term, they will represent non-secure origins in the same way that they represent Dubious origins. Then, in the long term, the vendor might decide to represent non-secure origins in the same way that they represent Bad origins.
>>
>>
>> Ultimately, we can even imagine a long term in which secure origins are so widely deployed that we can leave them unmarked (as HTTP is today), and mark only the rare non-secure origins.
>>
>>
>> There are several ways vendors might decide to transition from one phase to the next. For example, the transition plan could be time-based:
>>
>>
>> T0 (now): Non-secure origins unmarked
>>
>> T1: Non-secure origins marked as Dubious
>>
>> T2: Non-secure origins marked as Non-secure
>>
>> T3: Secure origins unmarked
>>
>>
>> Or, vendors might set thresholds based on telemetry that measures the ratios of user interaction with secure origins vs. non-secure. Consider this strawman proposal:
>>
>>
>> Secure > 65%: Non-secure origins marked as Dubious
>>
>> Secure > 75%: Non-secure origins marked as Non-secure
>>
>> Secure > 85%: Secure origins unmarked
>>
>>
>> The particular thresholds or transition dates are very much up for discussion. Additionally, how to define “ratios of user interaction” is also up for discussion; ideas include the ratio of secure to non-secure page loads, the ratio of secure to non-secure resource loads, or the ratio of total time spent interacting with secure vs. non-secure origins.
>>
>>
>> We’d love to hear what UA vendors, web developers, and users think. Thanks for reading!
>
>

Which standards bodies are those? Cause the W3C TAG is recommending pervasive end-to-end transit encryption.

On Wed, Dec 24, 2014 at 5:43 PM, Alex Russell <sligh...@google.com> wrote:
> Which standards bodies are those? Cause the W3C TAG is recommending
> pervasive end-to-end transit encryption.

That change in attitudes and recommendations hasn't retroactively caused change in software is...well...the state of all human affairs.

New APIs are absolutely being denied to HTTP content (see WebCrypro and Service Workers). The TAG will continue to recommend this. Stay tuned for the Finding.

Regards

> On 26 Dec 2014, at 22:20, Jiri Danek <software...@gmail.com> wrote:
>
> Have there been any suggestions what to do about <FORM>s sent over HTTP that include <INPUT type="password">? For example marking the password field itself as dubious/insecure? (I am absolutely not saying that is what browsers should be doing, mind you)

> If we want to talk about the perspective of servers, the server has options
> to demand a secure connection too; it simply has to deny plaintext requests

On Fri, Dec 26, 2014 at 8:33 PM, Austin William Wright <a...@bzfx.net> wrote:
>
> On Wed, Dec 24, 2014 at 3:43 PM, Alex Russell <sligh...@google.com>
> wrote:

On Dec 26, 2014 10:01 PM, "Austin William Wright" <a...@bzfx.net> wrote:
>
>
>
> On Fri, Dec 26, 2014 at 7:43 PM, Jeffrey Walton <nolo...@gmail.com> wrote:
>>
>> > If we want to talk about the perspective of servers, the server has options
>> > to demand a secure connection too; it simply has to deny plaintext requests
>> > ...
>>
>> Actually, no. Middleware boxes and a class of active attackers can do
>> whatever they want.
>
>
> Ah yes, I wasn't even considering the class of active attacks, where *any* attempt to go over cleartext would be vulnerable. Thanks for pointing this out!
>
> (I was careful to specify that accepting the TCP connection, for the purposes of redirecting, could leak information to eavesdroppers.)
>  
>>
>>
>> The control to stop most of the intercept related attacks - public key
>> pinning - was watered down by the committee members to the point that
>> the attacker effectively controls the pinset. (Here, I'm making no
>> differentiation between the "good" bad guys and the "bad" bad guys
>> because its nearly impossible to differentiate between them).

To Jeffrey: can you please stop the ad hominem attacks? Especially when the three authors have all worked on Chromium, and two are actively championing this proposal? This sort of revisionist history does no one any good. It is a simple threat model: If you give up administrative access to your physical device, it is no longer your device. The thing you lament missing due to some shadowy committee members (hi! No shadows here!) Is a simple recognition of two things: if your device is physically owned, it is physically owned, and no remote server can express a policy that clients will not be able to override, short of Trusted Computing and Remote Attestation (which is the tech term for saying once unicorns and fairies cease their blood feud and restore Santa Claus to his rightful throne in the North Pole... because it's all fiction).

I've avoided commenting all of the other times you've misrepresented how this came to be, but lest it be seen that our silence is assent, I have to at least call out this dissent.

>>
>> That is, the standard could have provided policy and the site could
>> have sent a policy that governed the pinset. The site could have
>> allowed an override or denied an override. But it was decided all
>> users must be subjected to the interception, so the policy elements
>> were not provided.
>>
>> So how's that for strategy: the user does not get a choice in their
>> secure connection and the site does not get a choice in its secure
>> connection. Rather, some unrelated externality makes the choice.
>
>
> I share your concerns, and more: Public Key Pinning (and Strict Transport Security, for that matter) is awfully specific to HTTP, even though it has nothing to do with HTTP at all. The proper place to put this information is in DNS records. This has worked reasonably well for Email; or at least I don't see anyone proposing we query SMTP servers for relevant security metadata.

I assume that you aren't familiar with STARTTLS? The encryption and security story for email is disastrously worse than anything for HTTP.

> So why do this for HTTP? (If one wants to answer that properly stopping forged headers is less important than stopping plaintext cat pictures, color me surprised; if it's because it's a better alternative than unencrypted DNS records for those lacking DNSSEC, that's a better answer, but it's still relegates HPKP and HSTS to the realm of "stopgap measure".)
>
> Austin.

Indeed. From the point of view of client applications, DNSSEC is a complete and utter failure, and will remain so for the next decade, given hardware cycles. If a decade sounds like a stopgap measure, when it was longer than the relevant lifetime of sites like Myspace, so be it, but that seems like a pretty good run to me.

On Dec 27, 2014 1:08 AM, "Austin William Wright" <a...@bzfx.net> wrote:
>
>
>
> On Fri, Dec 26, 2014 at 11:36 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
> (snip)
>
>> >>
>> >> That is, the standard could have provided policy and the site could
>> >> have sent a policy that governed the pinset. The site could have
>> >> allowed an override or denied an override. But it was decided all
>> >> users must be subjected to the interception, so the policy elements
>> >> were not provided.
>> >>
>> >> So how's that for strategy: the user does not get a choice in their
>> >> secure connection and the site does not get a choice in its secure
>> >> connection. Rather, some unrelated externality makes the choice.
>> >
>> >
>> > I share your concerns, and more: Public Key Pinning (and Strict Transport Security, for that matter) is awfully specific to HTTP, even though it has nothing to do with HTTP at all. The proper place to put this information is in DNS records. This has worked reasonably well for Email; or at least I don't see anyone proposing we query SMTP servers for relevant security metadata.
>>
>> I assume that you aren't familiar with STARTTLS? The encryption and security story for email is disastrously worse than anything for HTTP.
>>
>> > So why do this for HTTP? (If one wants to answer that properly stopping forged headers is less important than stopping plaintext cat pictures, color me surprised; if it's because it's a better alternative than unencrypted DNS records for those lacking DNSSEC, that's a better answer, but it's still relegates HPKP and HSTS to the realm of "stopgap measure".)
>> >
>> > Austin.
>>
>> Indeed. From the point of view of client applications, DNSSEC is a complete and utter failure, and will remain so for the next decade, given hardware cycles. If a decade sounds like a stopgap measure, when it was longer than the relevant lifetime of sites like Myspace, so be it, but that seems like a pretty good run to me.
>
>
> I would challenge this notion: The deployment cycle doesn't seem to be that much longer than TLS (underneath HTTP). SSL was first available in 1995, standardized 1996, almost twenty years ago. TLS 1.0 came out 1999 and we STILL have user-agents that will happily downgrade to SSL 3.0. (I don't claim to be a TLS/DNSSEC historian, feel free to correct me.)

I suspect we are far diverging from the topic at hand, so I won't respond in depth.

>
> While efforts to secure DNS began about the same time, the modern DNSSEC was first operational around 2004, and the first Key Signing Ceremony was only in 2010! I find it fully usable, for those applications that support it. At the application client level, I haven't found any reasons to not support it.
>

There are a tremendous amount of issues. Frankly, old hardware (e.g. systems running Windows XP, old home routers, old core routers) needs to go away. They either lack DNSSEC in any sensible level or they actively block it.

Again, this isn't an opinion: support for DNSSEC in client networks and on client software is awful. Not a "fix Chrome" awful, but "fix the Internet, the software stack, the OS" awful.

Beyond all of the operational security issues (which EXCEED those of CAs in many ways), the reality is that it is IPv6 in a pre-RFC 3542 world.

> I would venture to guess that Web browsers and other user-agents could make a better impact by deploying DNSSEC support, over forcing TLS usage. The former adds more options for security; the latter imposes costs on users of TLS, whether or not the existing system suits their needs.

Nope. Wrong wager.

>
> I don't see anything wrong with STARTTLS; in fact I find it preferable to having seperate URI schemes for what is otherwise the same resource. (I don't actually run any email servers, but I use STARTTLS with LDAP, XMPP, a proprietary protocol, and the similar RFC 2817 for HTTP. That is, in fact, a thing.) If one requires security, they can always start requests with "STARTTLS"; if a server demands security (for its definition of security), then it can just kill plaintext queries.

Again, as with HTTP, an attacker can easily strip out the STARTTLS. There are many who already do. The server cannot reject plaintext queries - the attacker need just SSLStrip them.

In short, it provides zero effective security without supplemental out of band policy.

> Nor do I find deployment of TLS on email systems to be particularly behind TLS on HTTP (do you have data on this?).

Multiple organizations, including Google, provide scorecards on TLS support.

There is no question it is behind compared to HTTP.

But more importantly, and to the point in which I was originally responding:
1) SMTP/IMAP do not use DNS to deliver security policy.
2) DNSSEC is a presently-failed technology. That it might improve is a possibility, but not with today's internet
3) DNSSEC is less secure than the CA system, for many reasons
4) most importantly, the lack of a scheme and the opportunistic encryption employed by SMTP make it no different than HTTP - an active attacker can break confidentiality, integrity, or authenticity with near-zero effort, and in a way that people would be surprised to realize.

People assume that emails are like letters in envelopes, when in reality they are postcards. Comparing HTTP to email would be one of the few things doable to make it worse.

On Fri, Dec 26, 2014 at 8:12 PM, Brian Smith <br...@briansmith.org> wrote:

> Even Chrome's 58% number is probably under-estimating the number of
> navigations that *could* happen loaded over HTTPS. I think a key to
> making a successful UI change like the one proposed is to identify
> HTTP loads that could be HTTPS loads, and actively make them HTTPS
> loads, similar to what HTTPS Everywhere does. Both browsers do this
> with HSTS and HSTS preloading, but that approach is too conservative.
> We need to find a way to measure this gap between "could be HTTPS" and
> "is HTTPS" and then more actively close that gap.

> It would also be useful to consider search metrics. When I search for
> "RFC 5246" with Google Search or Yahoo! Search, the top result is
> http://tools.ietf.org/html/rfc5246. But,
> HTTPS://tools.ietf.org/html/rfc5246 has the exact-same content. How
> often does this happen? What can be done to make search engines
> consider the HTTPS:// variant the canonical, default, choice? (Note:
> RFC 5246 is the TLS 1.2 specification.)

> Are the Chrome numbers available broken down by geography and/or
> language? I think it is likely to be the case that different
> populations (e.g. German language websites vs. Chinese-language
> websites) have quite different mixes of HTTP vs. HTTPS usage.
> Comparing some of the country-specific Alexa lists seems to support
> this idea. Peoples' understanding and reaction to security indicator
> changes is likely to be varied by locale too. Also, it is likely that
> some locales will reach whatever thresholds for triggering a UX change
> well before other locales. Should such UX changes be rolled out
> separately by locale?

On Mon, Dec 29, 2014 at 12:59 PM, 'Chris Palmer' via Security-dev
<securi...@chromium.org> wrote:
> On Fri, Dec 26, 2014 at 8:12 PM, Brian Smith <br...@briansmith.org> wrote:

>> It would also be useful to consider search metrics. When I search for
>> "RFC 5246" with Google Search or Yahoo! Search, the top result is
>> http://tools.ietf.org/html/rfc5246. But,
>> HTTPS://tools.ietf.org/html/rfc5246 has the exact-same content. How
>> often does this happen? What can be done to make search engines
>> consider the HTTPS:// variant the canonical, default, choice? (Note:
>> RFC 5246 is the TLS 1.2 specification.)
>
> Yeah, that's a bug we need to fix. I think we gradually are? I have
> pinged the relevant people.

On Mon, Dec 29, 2014 at 8:01 PM, Jim Manico <jim....@owasp.org> wrote:
>> Of the things that apply now, what sites can be doing is:

> 1) Ensuring HTTP redirects to HTTPS
> 2) Use canonical URLs - see
> https://support.google.com/webmasters/answer/139066?hl=en
> 3) Use HSTS, when available.
>
> I think that HTTP-redirect as a solution is "too late". The ••preloaded••
> HTST headers initiative seems to be the right solution in order to avoid
> that initial HTTP request...

>
> https://hstspreload.appspot.com/
>
> I don't think preloaded HSTS is part of the HSTS standard. How could we
> raise adoption?
>

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

On 3/01/2015 08:15 am, Jim Manico wrote:
> Craig,
>
> I would agree with the later perspective you are stating 10 maybe 5
> years ago, Craig. But with so many incredibly highly-visible hacking

> be bold at the standard level, possibly even get all of the major
> browsers to agree to said standard, and be a bit more aggressive in
> application security education and awareness in the browser. How much
> can that slider be increased? I'm not sure.

> But again I really think
> this one, forcing a password field to be transported encrypted, is such
> a low bar in terms of increasing security in the browser.
>
> So when a developer allows a users credential to be sent plaintext, it's

> without any attempt to warn the user or developer, then I call the
> browser a serious accomplice in this terrible and very basic security
> crime.

> On 1/2/15 9:55 PM, Craig Francis wrote:
>>
>> On 2 Jan 2015, at 22:09, Jim Manico <jim....@owasp.org

>> <mailto:jim....@owasp.org>> wrote:
>>
>>> So I say the browser absolutely knows that the data is - it's data
>>> that is sent over a field that a developer specifically labeled as a

>>> threatscape.
>>
>>
>> Hi Jim,
>>
>> I really appreciate what you're saying, and I would really like this
>> as well.
>>
>> But think about it from the typical programmers point of view... their
>> customers/managers might complain that the password field "looks odd"
>> (the warning approach - where they won't read the error message,
>> that's too difficult)... or does not work at all.
>>
>> That developer might implement HTTPS... but in most cases (because
>> they don't have time, or possibly too lazy, with a manager saying
>> "just fix it, and there's no budget for this"), they will just change
>> the input type to "text"... and possibly copy/paste a jQuery plugin
>> that will "bring back the dots", e.g.
>>
>> http://www.jqueryscript.net/form/iOS-Like-Plain-Text-Input-of-Password-with-jQuery-mobilePassword-Plugin.html
>>
>>
>> http://css-tricks.com/better-password-inputs-iphone-style/
>>
>> That's assuming the developer does not say that the browser is broken,
>> and they should use a different one (I've unfortunately seen this
>> response a few times before).
>>
>> Craig
>

> Only mild comment I'd make is that the whole '****' thing is soooo 1980s.  I'm specifically talking about university terminal labs, where students would shoulder surf to steal accounts.  These days, people want (need) to see the passwords in clear on the screen because they are so bloody difficult to type because they have to read an 8 hieroglyph masterpiece out of a paper or phone record to keep them secure.

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

> It's one of the reasons I'm really pushing for a security tab in the web dev tools, to help with education and usage of the features that are available... i.e. have you tried implementing a CSP header before? it's good fun :-)

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