
Marking HTTP as Non-Secure - diafygi
https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
======
andrewstuart2
I think the best time to do this would be soon after the Let's Encrpyt free CA
[1] starts handing out certificates. There's no more good reason not to have
HTTPS, so that's a good time to start applying a little pressure and adding
the incentive for website authors.

Does google already reward secure sites with higher search rankings? I can't
decide if I think that's a good idea or not, but if they want to push for a
more secure and free web, that's definitely another avenue.

[1] [https://www.eff.org/press/releases/new-free-certificate-
auth...](https://www.eff.org/press/releases/new-free-certificate-authority-
dramatically-increase-encrypted-internet-traffic)

~~~
Touche
I still haven't heard a reason why it's important that my blog is on https.
Waiting.

~~~
pdkl95
1) Sometimes it's not about _you_.

Currently, the NSA (and others, presumably) consider the _presence_ of
encryption as part of their is_suspicious() heuristic. Other people do have
need for encryption, and by saying "I (currently) have nothing to hide", you
are saying that you are fine with a high correlation between "uses encryption"
and "is doing something suspicious". More than any other reason, we need to
dilute that correlation until all data looks similar to remove the possibility
of this kind of categorization.

2)
[https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html](https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html)

As Zimmermann said, we need to socially normalize the use of envelopes instead
of the postcards that are currently used. Without that social expectation, it
will be possible to legislate against the use of encryption in the future.

3) It lets us (in the very long term) simply retire 80/tcp

...and plain HTTP servers in general. Sure, this is a minor benefit, but it
would still be nice.

~~~
arielm
While those are all valid reasons they land on the "greater good" side of the
scale, which doesn't have the obvious "what's in it for me" I think many
people are looking for.

My thoughts

1\. Not having secrets - MITM isn't necessarily conducted by malicious
attackers, but that doesn't mean it's bad. Consider for example a company that
wants to identify usage behavior and buys traffic data from an ISP. While the
data may be anonymized it's still someone's usage. With https, a webmaster is
limiting the info those companies can get so instead of being able to run a
complete analysis on the type of text a user reads and images they see, over
https they could only tell what websites you go to. It's still pretty bad, but
not as bad.

2\. Cost - I do see the value of cheap hosting on S3 and getting redundancy.
I've been hosting servers from the days before AWS existed (I started young)
and know one thing - if you can't afford something you probably don't need it.

Why does you $0.06 site need to have a multi node setup? I don't mean to sound
like a jerk but if you had the kind of traffic a multi node + DSL site needs
you'd probably have the funds to invest in it. It's really not very expensive
considering a cup of Starbucks coffee costs 100 times what you currently pay
for hosting...

If your content isn't secret why not go with a cheap SNI that can host your
certificate and put that behind cloudflare (which is free)?

~~~
pdkl95
> "What's in it for me"

I'll ignore he obvious selfish nature of this question and simply point out
that you may need to take advantage of that "culture of always encrypting
everything at some point in the future. It is incredibly short-sighted to
assume that you're not _ever_ going to be a target.

> "not having secrets"

You can look the numerous rebuttals for this very well-known fallacy.

> Cost.

It's probably worth mentioning that I am currently living on SSDI (social
security disability income) thanks to some unfortunate medical issues. I
_cannot_ actually afford _any_ PKI cert and related costs, even $20 costs.

Well, the EFF may soon have a free solution for this, and almost all of the
benefits I list are still valid even when the crypto is relying on an self-
signed certificate automagically generated by apache on first use.

I would love to see more options that address the cost issue - secure
communications should not be limited to those that can afford various economic
barriers, but for now at least some solution exists.

~~~
gaadd33
What's wrong with StartSSL for your use?

~~~
pdkl95
You assume they are always available and always do business with everybody? I
had an account with them once, but they declined to reinstate it shutdown the
account. I don't know why.

So no, they are not an option for everybody.

------
comex
On a related tangent:

In the new secure-by-default world, what happens if a website has some large
assets (e.g. video, game files) and would like to opt into caching by any
transparent proxies that may be on the user's network? The site could embed
hashes of the assets in question, and use ServiceWorker to transparently
inject a hash check into any fetches (no matter what HTML thingy initiated
them), but I think requests to http: from https: are always blocked as mixed
content - let me know if I'm wrong. Also, this would still send things like
user-agent, language, any non-secure cookies, etc., and allow the
unauthenticated server to set them; it would be good to have a way to opt out
of all these things, just sending a minimalist HTTP request instead.

Of course, even if these issues are fixed, any system allowing caching of
assets must allow tracking of what assets were requested; for some sites this
is unlikely to provide much info beyond what the domain name already
indicates, but for others it would be best to avoid. On the other hand, if
assets have sufficiently distinctive sizes, a proxy might be able to guess
this information over HTTPS anyway through simple traffic analysis, so it
wouldn't be that harmful to run it over HTTP instead.

~~~
JoshTriplett
One of these days, I'd like to have a scheme for referencing secure third-
party content that includes hashes. I'm never going to link to a third-party
server for some JavaScript file that could be changed out from under me, but
if I can link to it on a CDN along with a sha256 or similar, and have it
grabbed from my own server instead if the hash doesn't match, great!

I've seen a few attempts at that, but nothing that has actually taken off. It
needs an appropriate polyfill, so that in browsers that don't support it,
either the content gets downloaded and hashed client-side, or the content just
gets downloaded from the same origin.

> In the new secure-by-default world, what happens if a website has some large
> assets (e.g. video, game files) and would like to opt into caching by any
> transparent proxies that may be on the user's network?

The whole concept of a "transparent" proxy will hopefully die in a secure-only
world. If you want some server on your network to MITM your traffic (for
caching or any other reason), use a non-transparent proxy. (Or, install a CA
certificate from your proxy, but hopefully widespread use of certificate
pinning will kill that too.)

~~~
bzbarsky
For what it's worth,
[http://w3c.github.io/webappsec/specs/subresourceintegrity/](http://w3c.github.io/webappsec/specs/subresourceintegrity/)
is actively being worked on, and implementations in Chrome and Firefox are on
the way in the near future. The polyfill issue is handled in that proposal as
described in
<[http://w3c.github.io/webappsec/specs/subresourceintegrity/#f...](http://w3c.github.io/webappsec/specs/subresourceintegrity/#fallback-1>):
Your "src" attribute points to a server you control, but your "noncanonical-
src" points to the CDN, and a browser that knows about "noncanonical-src" is
also supposed to know about the "integrity" attribute and ensure that the
content it gets hashes to what you expect.

~~~
hrjet
This is very interesting; thanks!

I am not very familiar with hashing algorithms, but why isn't the length of
the content specified in the `integrity` attribute? Wouldn't it help avoid
length extension attacks?

~~~
JoshTriplett
A good digest alorithm should already handle length extension attacks with
just the digest. HMAC algorithms handle that as far as I know, and I _think_
modern hashes don't suffer from the length extension problem in the first
place.

~~~
comex
In any case, length extension attacks apply to (hashes misused as) keyed
message authentication codes - a scenario where you give a message and its
authenticator to a server knowing the key, and it checks whether someone
knowing the key generated them. The attacks let you, given a message and its
authenticator, calculate the authenticator for a different message. However,
in this case, the hash cannot be tampered with; breaking integrity would
require finding a different message with the _same_ hash, which is a straight-
up collision, considered to totally break a hash algorithm. At the moment, the
only commonly used hash algorithm with known collisions is MD5; SHA-1 will
probably follow in the next several years.

~~~
hrjet
I perhaps used the wrong term. I meant straight-up collision with a modified
length.

The known MD5 collision attack needs to modify the length of the message;
finding a collision with the same length is extremely difficult. It would be
reasonable to assume that attacks on other hashing algorithms would suffer the
same constraint.

Wouldn't having the length specified in the integrity attribute help reduce
chances of a future attack? The cost of specifying the length is negligible;
about 12 bytes for a base-64 encoded 64-bit unsigned int.

~~~
sjy
You're essentially using the length as a(n extremely weak) secondary hash in
that case. That might be sufficient to disable one known MD5 exploit, but if
you're worried about vulnerabilities in your primary hash algorithm it would
make more sense to use another real hash algorithm for your backup.

~~~
hrjet
Thanks for the answer. I am really not familiar with the mathematics of hash
algorithms and I ask just to learn.

Why is length essentially a weak hash? Isn't it an additional constraint that
works orthogonal to the hash? It serves to restrict the space of collisions
and hence directly reduces the exploit surface. Moreover, the length can be
independently verified of the hash function, and its space & time complexity
is negligible.

~~~
Dylan16807
> Why is length essentially a weak hash?

It's utterly trivial to match by itself. Adding length to a real hash is a
mild difficulty increase. Adding a second hash is a massive difficulty
increase.

> Isn't it an additional constraint that works orthogonal to the hash?

Yes. But so is a second hash.

> It serves to restrict the space of collisions and hence directly reduces the
> exploit surface.

Very inefficiently.

> Moreover, the length can be independently verified of the hash function, and
> its space & time complexity is negligible.

A second hash is independent of the first hash too. Hashing a second time
compared to downloading and hashing the first time is pretty close to
negligible.

------
randomwalker
One of the surveillance attacks pointed out in the post is the NSA
piggybacking on advertising cookies. Details in the Snowden leaks were scant,
so we did some research to figure out just how far the NSA could go with this
technique. Very far, as it turns out. Here's a blog post with a link to our
research paper: [https://freedom-to-tinker.com/blog/dreisman/cookies-that-
giv...](https://freedom-to-tinker.com/blog/dreisman/cookies-that-give-you-
away-the-surveillance-implications-of-web-tracking/)

One of our conclusions was that tracking companies switching to HTTPS would
help, but a large majority would have to switch to make any difference,
because of the sheer number of trackers (Section 4.1). This proposal or
something like it is probably necessary if we're to see that magnitude of
change.

------
diafygi
Previous discussion in

Firefox:
[https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...](https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/iU86qMOwvWs)

[https://bugzilla.mozilla.org/show_bug.cgi?id=1041087](https://bugzilla.mozilla.org/show_bug.cgi?id=1041087)

Chromium:
[https://groups.google.com/a/chromium.org/forum/m/#!topic/sec...](https://groups.google.com/a/chromium.org/forum/m/#!topic/security-
dev/DHQLv76QaEM)

[https://groups.google.com/a/chromium.org/forum/m/#!topic/sec...](https://groups.google.com/a/chromium.org/forum/m/#!topic/security-
dev/rGM2oiKZqZU)

------
zerocrates
If you make a change like this too quickly, you run the real risk of users
seeing the "warning" so often that they just get trained to ignore it (even
more than they already do).

~~~
nkozyra
A fair argument, but what's the gradual approach? It has to be all or nothing.

The idea behind this is to use it as an impetus for sites and services to move
to SSL/TLS.

~~~
gojomo
There's a very interesting idea at the end of this proposal: that the more-
aggressive warnings arrive based on telemetry of the preponderance of secure
interactions. By changing over time, and in a manner sensitive to the real mix
of user interactions, there's less risk of habituation to "oh, all sites show
that warning".

You could even make the switch based not on the entire browsers' usership, but
an individual user's recent past. (Not sure this is a _good_ idea, but it's an
interesting one.)

------
fiatmoney
_Excellent_. While they're at it, maybe they should stop marking self-signed
SSL as more of a security risk than plaintext HTTP.

~~~
driverdan
They currently _are_ more of a security risk because if you tell the user
their connection is secure when it's not (no verification of self-signed
certs) you impart a false sense of safety.

~~~
lstamour
If you perform certificate pinning, self-signed can be just as secure. I wish
the message was slightly less scary, perhaps saying as SSH does, "you've never
visited this site before, do you trust this certificate?"

~~~
coldtea
(user clicks "yes" and proceeds oblivious)

~~~
baq
as opposed to unencrypted HTTP?

~~~
Too
I can teach my computer illiterate grandma simply _" never do email unless the
address bar is green"_, she can remember that.

As opposed to: _Never do email unless unless the address bar is green, except
when:_ \- It's the first time you visit the web site \- You use another
browser \- You bought a new computer/tablet/phone, reinstalled your computer
etc. \- You accidentally cleared your browser history \- You are on a public
wifi the very first time you visit a web site. \- The website changed their
certificate since last time you used it. \- You happen to be unlucky and even
at home you are under a MITM-attack the very first time you visit the page.

The last bullet is especially troublesome because even a programmer would have
a hard time to judge that one.

------
josteink
This is just pointless scaremongering.

Remember what happened when msie added warnings for this a decade ago?

People got so fed up with "security"-warnings that they just clicked "OK! OK!
Whatever. Get the fuck out of the way!". And they did it to ALL warnings,
serious ones too.

Glad to see history repeat i itself.

~~~
zerolinesofcode
Agreed.

There are so many websites on the internet which do not gather sensitive data
from the users but display read-only content.

~~~
tomjen3
If you had checked my web-browsing over the last week it wouldn't be very hard
to make an argument that I should be in psych facility, based on the number of
suicide related searches I did. In all cases it was purely static content, but
in the wrong hands it could be a huge issue for me.

I am only posting it here to prove a point: even static content can reveal a
lot.

~~~
byuu
I don't think SSL is all that great for protecting broad interests.

If you are going to ten different domains in the same span of time that all
contain suicide content and someone is snooping your connection, they can
correlate what you're doing from the server names (especially if one of the
domains has the word 'suicide' in it), even without seeing the page content or
path portions of your web requests.

For exclusive content sites, it's a dead giveaway. If someone went to my
domain (byuu.org) in HTTPS, then it's pretty obvious that they were interested
in emulation, regardless of the encryption. There's already tons of services
out there categorizing domains on the internet.

SSL's primary benefit is for form submissions, not for static content pages.

For something like that, your best bet at the present time is a service like
Tor. Which even that isn't really perfect.

------
sdrinf
Synthesis: Chrome Security Team would like to put :( for all non-secure HTTP
connections. With gradual deployment, and increase of all active sites moving
to HTTPS, it is assumed that users won't become trained to ignore this as a
warning signal.

| Then, in the long term, the vendor might decide to represent non-secure
origins in the same way that they represent Bad origins.

The biggest disadvantage of the proposal, as it stands in current CA climate,
is that it's psychologically successfull deployment will impose a liability
for site operators to touch their sites at least once per CA renewal
timeframe. There are many sites where this isn't desired, feasable, or even
possible at all, but which despite non-security, still serves giant heaps of
high-quality information. So, this will increase SEO, and accessibility gap
between sites run by geeks, and sites (attempted to) run by everyone else.
Whether this is a desired future of the web is left to an exercise for the
dear reader.

~~~
icebraining
The Let's Encrypt project will have a daemon that automatically renews the
certificate.

------
Animats
From the article:

 _" 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."_

...

 _" You do not have permission to add comments."_

~~~
dlisboa
It's pretty obvious they're intending the discussion to happen on mailing
lists.

    
    
        We’d love to hear what UA vendors, web developers, and users think. Thanks for reading! We are discussing the proposal on web standards mailing lists:
        public-webappsec@w3.org
        blink-dev@chromium.org
        security-dev@chromium.org
        dev-security@lists.mozilla.org
    

You make it sound like they're eschewing discussion.

------
ajnin
Great. So with this proposal all website operators that don't pay their due to
the Certificate Authority cartel will be marked as "bad" sites. I'm all for
restoring trust but not before the CA issue is resolved.

------
cryptolect
Ever since I realized there will be a persistent log of my browsing history
maintained by one or more government agencies, I have mentally-marked http as
risky. I cannot wait for something like this to happen, and encourage the
wider less-informed community that TLS is critical for both trust (properly
implemented, TLS will provide protection against tampering and data leakage)
and to provide a minimum level of privacy (I can see you visited site x, but
not what sections of it). Bring it on.

------
jstsch
Hmm, there are a _lot_ of sites out there. So many small sites with their own
domain name. Local establishments, projects, clubs, communities... that will
be hell to migrate, with non-obvious benefits to most site owners.

This might force more centralisation of the web again... just move your
content to ESTABLISHED_GLOBAL_PLATFORM_X instead of that vhost at
SMALL_LOCAL_PROVIDER_Y.

~~~
undefined0
If LetsEncrypt comes pre-installed with cPanel and when creating the domain
name it's https by default, then as long as shared hosting providers update
the cPanel then all small sites will be updated to be ssl by default. But then
we'd have the problem with people continuing to use '[http://'](http://') in
<a> tags.

------
lnanek2
Really not happy with the way Chrome is going on these things. As a web
developer, sometimes the best thing for my users is an HTTP media file off a
non-SSL CDN closest to their home and cacheable by things like Squid stuck in
front of them in my HTTPS otherwise page. But I can't do that now because
Chrome will display the page as broken. They are just taking useful tools away
from developers to improve the lives of users and not really improving
anything except for a few privacy nuts who care about every tiny image on
every page possibly being tracked.

~~~
tomjen3
That is easily solvable: make internet connections fast enough that caching is
no longer an issue.

~~~
jacquesm
It is rarely the speed of the connection that makes caching an issue, but much
more frequently the cost of the generation of the data and the cost to
maintain that data post generation.

------
steve_taylor
Marking HTTP as non-secure implies that HTTPS is secure. The large company
where I work has quietly rolled out the Zscaler HTTPS proxy and my colleagues
are unaware that, despite the assurance given by the green padlock in their
browser, their connection is most definitely not secure.

~~~
tomjen3
That is because browsers obey the false root certificate installed locally,
even when they otherwise pin the certificate down. This is a deliberate
choice, but that doesn't mean HTTPS isn't secure, it means that you can't
trust a computer you don't control.

------
bonsai80
My vote for the icon to use would be a small frown or disappointed face. It's
different than the icons for broken https, but still gets the point across
that something isn't so great.

Here's what I'm thinking of: [https://cdn0.iconfinder.com/data/icons/smile-
emoticons/78/Em...](https://cdn0.iconfinder.com/data/icons/smile-
emoticons/78/Emoticons_smile_smiley-03-512.png)

~~~
Too
Why not a postcard for insecure and envelope for secured? Might be hard to
distinguish in small icons and can be confused with email too easily but
otherwise the message should go through.

Can't be worse than padlocks with different shades of green as we have today
anyway. Does anyone actually understand them? Here on HN i get a gray padlock,
on some other site i get a green padlock and on yet another site i get a
padlock and a nice fancy badge with the website name in it. Doesn't help that
every browser keep changing their looks with regards to this every 6 months
also.

------
ademarre
> _We know that people do not generally perceive the absence of a warning
> sign. 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._

That is a very strong point. User perception of the browsers' current UX
treatments of the various security scenarios poorly represents the true level
of security. An insecure HTTP site (no warnings) looks safer than an HTTPS
site which happens to reference a single non-HTTPS image (mixed content
warning). The absence of a warning for the HTTP site is not fair, because
despite the mixed content, data submitted in a web form to the HTTPS site is
still encrypted, yet the UX treatment affords it less trust.

Separately, how should Extended Validation (EV) certificates fit into this
plan? Especially after the final proposed transition phase, _T3: Secure
origins unmarked_. Personally, I think EV certs have become kind of a racket
in the CA industry. But they exist nonetheless, and we should push for more
consistent browser treatment of site security in general, including consistent
treatment of EV certs.

------
hartator
I think that can be scary for the wrong reasons. Like a whole part of the web
will be marked as "non-secure" where it should be marked as "non-encrypted."

Security-wise, MIM (Man in the Middle) attacks using HTTP are a fraction of
the real security threats (Phishing that can use https!, Keyloger, Malware,
Browser Vulnerabilities...)

It will give too much weight to HTTPs websites or too little to HTTP websites.

Moreover, SSL certificates are expensive!

------
zzzcpan
Maybe showing the "http-is-insecure" warning in the address bar only when the
user fills form inputs?

~~~
robszumski
This would be a great first step, maybe a new T0.5 in the transition plan. Get
people on board by securing the data they are sending around, and the secure
the pages they are reading later.

------
general_failure
Great move. We also need free/cheap wild card certs.

------
1stop
Even with HTTPS if you compromise the server, or the client you can do
whatever you like... so my awesome server with all ports open and with login
(on everything): admin password: 123 serves some content, but has a valid
certificate, and the browser says: "This Connection Is Secure!"

Meanwhile a well managed server with no open ports, private key auth etc, but
serves content without HTTPS, the browser says "This Connection Is Insecure!".

Seems a bit misguided to me. Also feels a little corrupt and profit driven (by
CAs)... Why don't google offer free Certificates... seems an obvious (and
trusted) way to spread more "Certified websites".

~~~
chavesn
I'm not sure I follow your argument. You do realize that you are talking about
two different kinds of attack channels right?

Cleartext-based attacks and snooping (middleman, network peer) are simply far
easier and far more likely.

You know those happen all the time, right? Literally all the time for certain
users in certain places. A cleartext exploit is source-based (or route-based)
and the server owner can't _ever_ do anything to fix it besides forcing
encryption (or shutting down completely to that source).

In contrast, a server compromise is destination-based and will theoretically
only exist for the time that it is not known to the server provider.

~~~
userbinator
On the other hand, cleartext-based attacks are also more easy to _detect_
since the traffic is plainly visible. The maliciousness doesn't always have to
be outside, despite all the focus on surveillance recently; and when it isn't,
a "secure" connection makes it even harder to detect until it's too late.

Here's a recent demonstration of this principle - "smart TVs" phoning home via
an unencrypted connection: [http://arstechnica.com/security/2013/11/smart-tv-
from-lg-pho...](http://arstechnica.com/security/2013/11/smart-tv-from-lg-
phones-home-with-users-viewing-habits-usb-file-names/)

If that was over HTTPS, would such data collection have been as obvious or
even discoverable? It would be completely indistinguishable from any other
"phoning home" \- e.g. to legitimately check for software updates. The same
encryption technologies that purport to protect us from mass surveillance...
can be used to do it even more stealthily, and this is the main concern I have
with making encryption ubiquitous.

~~~
chavesn
Interesting, though I don't know how this is really relevant to the debate
about whether it's appropriate to tell a user that HTTP is insecure but HTTPS
is secure (the comment I was replying to questioned that exact point).

That's because the technology clearly exists to hide the type of phoning-home
you are talking about. Any move toward more HTTPS for end users doesn't seem
to increase that risk to me.

------
demarq
Some one explain this to me. If I use Https would I still be protected from my
own service providers (isp/carriers).

Surely anyone who can see the handshake can also decrypt what follows. I ask
this because I'm assuming this move is a reaction to all the NSA buzz that's
been in the media(assumption).

And I would figure the only way all the spying was going on is because one of
the parties we depend on for our internet services anywhere from the ISP to
the end server were compromised.

So how would HTTPS make a difference?

~~~
jMyles
> Surely anyone who can see the handshake can also decrypt what follows.

If I understand your claim here, it seems that you aren't yet familiar with
key pair cryptography.

It's not enough for someone to witness the handshake - they need to actually
possess the 'private' key of one a party in order to decrypt traffic that has
been encrypted with that party's 'public' key.

It's an amazing feat of mathematics; the fact that it is possible suggests, at
least to me, that the physics of the universe in some sense favor the
evolution of verifiable private communications.

Here's the wikipedia article on key-pair crypto (often simply called "public
key crypto"): [http://en.wikipedia.org/wiki/Public-
key_cryptography](http://en.wikipedia.org/wiki/Public-key_cryptography)

~~~
demarq
Thanks!

------
mlaretallack
This sounds like a good idea and a step on the right direction. However
working in the embedded world, no one has yet created a system for using https
that does not involve a lot of complex steps to prevent the browser from
warning of an insecure link.

It would be nice if all browers worked more like Firefox where it is easier to
add exceptions.

Going forward I can imagine the conversion I am going to get, "why does the
brower say that my traffic controller is insecure?"

------
alxmdev
I hope they'll label mixed content pages the same way as plain HTTP, it might
motivate all the big websites that still get this wrong to get their act
together.

------
totony
A better approach would be, in my opinion, to only show insecurity when a
<form> or user input is requested, i dont really see the use in https
everywhere for small static websites.

DNS will still leak most of the websites you visit, so anonymity in this case
is not really the issue that will be resolved.

~~~
Confiks
DNS will only leak which hostname you visit, not which pages you access on
that hostname. You hereby definitely resolve a privacy issue.

Furthermore, the presence of a <form> element also looks like a very bad
measure for 'protectworthy' information to me. Websites that require a user
session to be established, need users to send a cookie for every request.
Those requests need to be secure, or the sessions can be stolen.

~~~
totony
Then, if there are sessions too, <form> was just an example.

You're right for the path though, but for a majority of users, this doesn't
matter, that is because a website often has a specific subject (porn, warez,
etc), so if one DNS lookups the website, then that pretty much gives it all if
the middle man is interested.

Read: My opinion is that it's useless for most people, and is problematic for
old infrastructures. Therefore there are as much benefit as negative effects,
or more negative effects, so it doesn't seem worth it.

------
sleepychu
Noooooooo! Why must the entire web be secure? I might run some micro news site
for my local church that I update manually with (S)FTP and html files - why on
earth should that connection be encrypted.

Bad security _should_ be marked as bad. No security is not inherently bad.

~~~
eslaught
I disagree. No security really is as bad as broken security.

I'm guessing you think your church website isn't worth securing because it
doesn't have any sensitive content. But in a world where surveillance is
pervasive, that's not something you should depend on. For example, if
religious discrimination were to lead to members of your church being harassed
because of their viewing habits, then the argument that the content isn't
sensitive doesn't seem so strong anymore.

~~~
illumen
Securing is different to encrypting.

Most tracking of people is done by advertising, and marketing companies.
Should we mark all websites with advertising as insecure?

~~~
xorcist
As much as I'd love that (seriously, not advertising per se of course but most
types of cross domain tracking), something tells me that initiative is not
going to originate from the Chrome team...

------
donniezazen
I have been looking into setting up SSL for my blog. There currently no free
way to get SSL certificates. There are some free ones but they tend to come
with strings and lure you into paid plans. I am not sure if this proposal is
the best.

~~~
pushrax
StartSSL is free and simple to use unless they changed recently. The only
downside is that certain UAs don't trust the StartSSL CA, notably Java.

~~~
donniezazen
The free version doesn't come with wild card. So if you run multiple stuff off
your VPS you will have to upgrade. I currently use self-signed certificate for
everything except when I serve content to public I switch to http.

~~~
pushrax
You could use SNI and support the majority of clients.

------
michaelbuckbee
This seems to describe a situation where sites served over plain 'http' would
pop a red 'x' or other distinguishing UI element to connote untrustworthiness.

This is almost the case already where a good number of browsers will show no
positive (green indicator or lock icon) for domain validated certs - showing a
preference for the much more expensive EV (Extended Validation) certs.

Screenshots of the different browser SSL level representations:
[https://www.expeditedssl.com/pages/visual-security-
browser-s...](https://www.expeditedssl.com/pages/visual-security-browser-ssl-
icons-and-design.html)

------
illumen
Sites with advertising should be marked as insecure. Since they have been
known to serve trojans, and also are used to track people without their
consent.

Will Google and Mozilla both do this? No. Because their revenue depend on it.

~~~
Maxious
Google and Mozilla have no problem blocking sites that use non-Google ad
networks as malware [http://marketingland.com/googles-chrome-browser-issues-
malwa...](http://marketingland.com/googles-chrome-browser-issues-malware-
warnings-for-major-news-sites-32520)

------
IgorPartola
To all those arguing that HTTP is still fine, please go ahead and drop ssh in
favor of telnet. Go ahead, I will wait. If you cannot figure out why HTTPS is
more secure than HTTP and why we should drop HTTP support from all browsers
entirely, then please go read about it. HTTP should be used no more than
telnet these days.

I am not saying HTTPS is perfect as is, but I am saying that HTTP is
fundamentally and practically broken at this point. It is exploited daily in
many different ways and your and your users' experience is worse because of
it. Stop using it, and help other stop.

</rant>

------
jcrites
> Secure (valid HTTPS, other origins like (* , localhost, * ));

Does this notation refer to any protocol and port on localhost? That's my
guess, but the meaning of the notation wasn't immediately clear to me.

------
raldi
Can someone explain this part?

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

Are parenthesis-asterisk and asterisk-parenthesis some kinds of special
origin?

~~~
bzbarsky
In modern W3C and WhatWG specs, an "origin" is either a (scheme, host, port)
triple or a nonce value. The asterisks in this case are being used as a
shorthand for "any origin which is a triple and whose host is localhost, no
matter what the scheme and port are".

------
justinph
This is a great idea, and I say this as the webmaster of many sites that are
not secure. I should be forced to get my but in gear and fix that.

------
cnst
So, looking at their screenshots...

How about prefixing the non-secure URLs by "[http://"](http://"), so that, you
know, people will be sufficiently warned that it's not
"[https://"](https://")?

------
tszming
I think this is a good start.

But it is also important to educate users that even you are using HTTPS, some
companies' internal network might not be fully encrypted and therefore it is
not fully secure against some three-letter government agencies :)

------
idibidiart
Related discussion with and in between W3C TAG members

[http://lists.w3.org/Archives/Public/www-
tag/2014Dec/0098.htm...](http://lists.w3.org/Archives/Public/www-
tag/2014Dec/0098.html)

------
edandersen
They should also mark as Non-Secure the situation when you are being MITM
attacked by your employer - custom root CAs on Windows boxes are quite common.

------
hobarrera
HTTP is not always insecure. Some environments (eg: LAN), can have network-
level security (eg: IPSec).

------
jacquesm
Since when is HTTPS secure?

------
sft
Google and others rarely ever mention DNS/DNSSEC, even though just as much
information is being sent insecurely in the form of DNS queries/responses.

Learn more:

[https://github.com/jedisct1/dnscrypt-
proxy](https://github.com/jedisct1/dnscrypt-proxy)

[http://dnscrypt.org/](http://dnscrypt.org/)

Check if you already have it enabled (unlikely if this is the first time
you're learning about this) [http://test.dnssec-or-
not.com/](http://test.dnssec-or-not.com/)

~~~
kissickas
Is this working for everyone else? I get a "server not found" message.

[http://downforeveryoneorjustme.com/http://test.dnssec-or-
not...](http://downforeveryoneorjustme.com/http://test.dnssec-or-not.com/)
tells me that the server is up.

~~~
sft
working fine here

there are others to check if you have it (I'm pretty sure you won't unless you
have explicitly set it up yourself)

google 'DNSSEC test'

btw setting up DNSCrypt-proxy takes all of 10 minutes on Windows

------
sft
can someone explain how we can save threads within our HN accounts? it's not
immediately obvious

------
BrickAddict
um...

------
bigeee22
Finally...

------
bigeee22
Long overdue. :)

