
Moving Towards a More Secure Web - kungfudoi
http://blog.chromium.org/2016/09/moving-towards-more-secure-web.html
======
cpeterso
Firefox 46+ adds a red "no lock" icon for [http://](http://) pages with a
password field. Chrome's explicitly saying "Not secure" is a big step beyond.
I hope it sticks!

[https://blog.mozilla.org/tanvi/2016/01/28/no-more-
passwords-...](https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-
over-http-please/)

~~~
johnnydoebk
I think the problem with the Firefox's "red" "no lock" icon is than it is
mostly gray. Many people do not even notice it. I think if it were actually
red the effect would be much stronger.

------
azureel
Every HTTP site is insecure, that's OK and we all agree on that.

But using HTTPS doesn't make a website magically secure, that is not enough.
Thus there might be a false sense of security via this option.

> My mom opens browser

> Goes to [http://www.example.com](http://www.example.com)

> Sees "insecure" flag, ok moves on.

> Than goes to [https://shady.example.com](https://shady.example.com)

> Oh nice padlock icon you got there

> It's secure, I can give my credit card info.

Maybe I'm exaggerating. Anyway, it's a good start. HTTPS everywhere, let's
encrypt!

~~~
cmdrfred
Don't the people who own example.com also own shady.example.com? example.net
would be a more likely case.

~~~
seanwilson
Maybe one subdomain is served over HTTP and the other subdomain is served over
HTTPS. Lots of sites still do this where the area you login to is under HTTPS
but the rest is under HTTP.

~~~
cmdrfred
Comment specifies the protocol used "Than goes to
[https://shady.example.com"](https://shady.example.com")

~~~
azureel
Yeap, you're right. I can correct the example;

> Goes to [http://example1.com](http://example1.com)

> Than goes to [https://example2.com](https://example2.com)

How about this one?

------
xg15
Interesting point which unfortunately got buried in this thread due to being a
reply to another comment:

[https://news.ycombinator.com/item?id=12457809](https://news.ycombinator.com/item?id=12457809)

 _> Why does Google profit from HTTPS over HTTP? Because it removes the
ability for ISPs to act as a competitor to Google by injecting ads and
profiling customer browsing. You may not like that ISPs have done that (I
don't) but it's competition for Google, and removing it is therefore good for
Google's profits._

~~~
DyslexicAtheist
the industry has previously responded by installing their own root
certificates into the trust-store of the OS. Mobile operator supplied versions
of android are a good example, ... on notebooks we got Lenovo, ...
[http://www.wilderssecurity.com/threads/superfish-is-not-
the-...](http://www.wilderssecurity.com/threads/superfish-is-not-the-only-
one.373647/)

Trusting certificates issued by CAs, companies that have no 'skin in the game'
(WoSign), or are too big to fail (Symantec, Comodo, ...) won't work for what
we actually want to do (securing the transport layer of critical
infrastructure, all the way to sharing economy, and even online-banking).

More HSTS/HPKP?

Certificate pinning (HPKP) is a great example of _" security as an after-
thought"_. Not that it's bad (HPKP is great if you know what you're doing) but
it's unpractical and can seriously brick your site. There are also several
other attack vectors against HPKP:
[https://news.ycombinator.com/item?id=12434585](https://news.ycombinator.com/item?id=12434585)

The solution isn't to bolt on more X509 on top of a broken foundation. It is
on the other hand so typical of how we fix issues in engineering.

------
slim
There's one component of the web that everybody seem to forget : the proxy.

HTTPS breaks proxies and breaks caching. Which is a crucial part of the
architecture of the web.

And that's a huge issue especially for developing countries. Bandwidth is
costly and the way telcos exchange does not help.

Most of our activity on the web is public as in a public space. That's fine
and maybe even actually good. There is no need to scare people from HTTP, we
should educate people on how to use public spaces on the internet

~~~
zeveb
> There's one component of the web that everybody seem to forget : the proxy.

> HTTPS breaks proxies and breaks caching.

I wonder if RFC 2660 S-HTTP[1] would have helped here.

> Most of our activity on the web is public as in a public space. That's fine
> and maybe even actually good.

I think what we've discovered is that this isn't actually true: many things do
need to be secret, and in order for things to be secret those things need to
hide in a cloud of things which don't really matter.

[1] [https://tools.ietf.org/html/rfc2660](https://tools.ietf.org/html/rfc2660)

~~~
slim
Secret from whom? Most of the information we're talking about is shared among
CDNs and Ad networks. It just gives a false sense of privacy to consider this
kind of information private

------
gooseserbus
The irony of posting this link as http when https is available

------
StavrosK
This is a great move towards more security. I can't _believe_ I remember a
time when Facebook's login form was over plain HTTP.

~~~
blowski
As was Gmail, I seem to remember.

~~~
magicalist
> _As was Gmail, I seem to remember_

I don't remember, but it doesn't appear that that was the case:

> _We use https to protect your password every time you log into Gmail, but we
> don 't use https once you're in your mail unless you ask for it_

[https://gmail.googleblog.com/2008/07/making-security-
easier....](https://gmail.googleblog.com/2008/07/making-security-easier.html)

~~~
blowski
Oh yes, you're right.

------
rocky1138
"more than half of Chrome desktop page loads now served over HTTPS"

This makes me happy to read.

~~~
bzbarsky
Would rephrasing as "more than half of Chrome desktop page load are Google or
Facebook properties" still make you happy? I suspect that's a very large part
of what's going on there.

------
zubat
Ok, but how do I get on the coffeeshop wifi if Chrome is my only browser and
it throws up a warning page with no "ignore and continue" before I can log in?

This is already an issue for me today. Fortunately I can still tell it to go
to example.com without issue, and log in from there. But if they stick up
warnings on http I may be in a position to have to have a second browser just
for wifi logins.

~~~
3pt14159
You can request a page that doesn't exist.

[http://verylongrandomstring.io](http://verylongrandomstring.io)

Should do the trick.

~~~
slavik81
Be sure to generate a different one for each connection attempt.

[https://github.com/sindresorhus/is-
up/issues/5](https://github.com/sindresorhus/is-up/issues/5)

------
bobajeff
Doesn't moving everything to https make the Web even more centralized? In
order to use it looks like site's have to submit to a certificate authority
now.

~~~
ajross
For some definition of "submit", I guess. Non-EV certificates are based on
domain ownership. If you can prove you own the domain (e.g. Let's Encrypt just
checks that you can host a static file on a HTTP page on the certified
hostname) then you can get a cert for it. Obviously you still have to "submit"
to the domain registrars also...

~~~
paulddraper
It was always centralized (though "federated" would be more accurate), with
allocated IP blocks and domain registrars.

------
bugmen0t
Btw, this web page has a nice overview of what security indicators look like
on different web browsers: [http://lock-museum.herokuapp.com/](http://lock-
museum.herokuapp.com/)

------
diegorbaquero
There's no excuse now that we have LetsEncrypt.

Thank you!

~~~
Mahn
LetsEncrypt still has some limitations though, namely no wildcard
certificates, which means you need to issue and update certificates for every
subdomain individually. Certbot helps, but it's still a hassle at a certain
scale. We'd gladly migrate to LetsEncrypt, but for us (+40 subdomains) it's
still far simpler to manage using a paid wildcard certificate from CAcert.

~~~
mordocai
To be fair, you can do a large amount of subdomains (I don't remember the
limit) with one certificate request on letsencrypt. Of course, if you're going
to be changing them often then it becomes a real PITA.

------
xg15
What I don't like about the whole HTTPS everywhere initiative is that it makes
it even harder to monitor what data is traveling to and from your own PC.

In case of browsers, it's luckily still only a theoretical concern today,
thanks to the "custom root cert" loophole which practically works like a
permission system for monitoring tools. However, I think the conceptual change
is important: With HTTP, the abillity to monitor your own connections is a
simple technical consequence. With HTTPS, its a feature that browsers
explicitely have to implement and that's potentially subject to all kinds of
tradeoffs and political descisions.

I fear that once HTTPS is actually the norm, there will be a number of strong
forces to have the loophope removed and make HTTPS connections effectively
opaque to everyone but the website operators.

Of course HTTP is no long-term solution as the security risks are real. But
you could get rid of most of the risks by focusing on ensuring message
integrity while keeping connections transparent. Instead we get an all-or-
nothing solution where a connection has to be integrity checked AND encrypted
to be considered "secure" by browsers.

~~~
extra88
I'm not concerned about that happening. I think EMEs being used for not just
video but entire page content is a more likely risk.

------
amelius
Shouldn't encryption be part of TCP/IP, rather than have every application
including web browsers reinvent the wheel?

~~~
tptacek
No, it should not. Security involves policy decisions; for instance, "how
should I respond when confronted with an expired certificate with a valid
signature", or, "how should I handle a certificate when I can't verify whether
it's been revoked", or "how should I handle a valid certificate for a pinned
domain".

Sometimes the answer is "just go ahead but lose the green bar".

Sometimes the answer is "pop a click-through warning". (We click through these
warnings, but they bounce significant numbers of end users).

Sometimes the answer is "scream bloody murder to the browser vendor".

What does it even mean to trust a signature? Do we trust things that come from
hierarchical PKIs? Would we rather rely mostly on key continuity, like SSH
does? Do we want to build something like Moxie Marlinspike's Convergence, long
term, so we can choose which authorities we trust?

All of these concerns that I listed _could_ be handled in an encryption
capability that resided directly in the transport layer. But we'd inevitably
come up with concerns that were difficult to handle there --- for instance, if
it's part of TCP/IP, the code is mostly kernel resident, and maybe it's super
hard (even harder than it is now) to get Curve25519 deployed.

This isn't so much insight on my part as it is the stated conclusion, about
security in particular, of Saltzer, Reed, and Clark's "End To End Argument In
Systems Design", which is one of the foundational documents of the Internet:

[http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...](http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt)

Push things as far towards the application layer as they'll go, and keep the
lower-layer protocols dumb, so they don't get in the way.

Here's a more reasonable approach that probably addresses the concerns you
have about there being multiple app-layer crypto protocols:

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

~~~
fulafel
IPSec admitted and reacted to this too late, but they were going to handle it
by giving the policy choices to the application through socket options. See
IPSec Channel Bindings RFC (RFC5660) and unfinished specs at
[http://www.potaroo.net/ietf/html/ids-wg-
btns.html](http://www.potaroo.net/ietf/html/ids-wg-btns.html) for where this
work was heading.

------
mkagenius
Nice. Mobile apps world should also move quickly. I had written about it
earlier here: [https://medium.com/@mkagenius/where-is-my-https-for-
mobile-a...](https://medium.com/@mkagenius/where-is-my-https-for-mobile-apps-
aa8bcece5954#.fksay64ms)

~~~
imajes
You mean like ATS on iOS 9+ ?

~~~
mkagenius
Yes! Android should also do something similar.

------
Cortez
But saying something is insecure doesn't make it secure.

~~~
StavrosK
Yes it does, it forces people to avoid it, indirectly forcing the creator to
make it secure.

~~~
Cortez
Avoiding it doesn't push to make it secure, communicating with the creator
directly will.

~~~
StavrosK
It's unreasonable to expect Google to email every website owner in the world
to tell them to switch to TLS.

------
toomim
A page can be http, but what matters is if the fork _submits_ to a https url.
Does chrome care about how the page was loaded, or what the form submits as?

~~~
cmg
If the page is plain HTTP, it's possible for there to be malicious edits -
adding a keystroke logger, changing the form's action to point to somewhere
else entirely that saves credentials and redirects back to the original
service the user meant to log in to, etc. So it matters very much that the
page with the credit card or password field is HTTPS.

~~~
Klathmon
And the even more sinister "include a malware payload into an asset which was
requested". Drive-by infection of exe's, injecting video streams with payloads
that can take advantage of the StageFright vulnerability, not to mention
things like session hijacking that can happen if any part of a page is loaded
over http.

HTTPS is all or nothing, an in-between "only on the pages that need it" isn't
going to cut it.

This is just the chrome team's first step (actually more like 5th or 6th step
in this plan) toward getting there.

~~~
xg15
Until of course you get similar vulnerabilities (Heardbleed etc) in the TLS
implementation itself...

------
frik
HTTP is fine for most websites. HTTPS makes sense for certain parts of
websites like e-commerce. Even Amazon website (beside .com) is HTTP with only
the login page and checkout page on a HTTPS sub-domain. It's fine since 1995,
and no one complains or has problems with that.

Labeling HTTP as insecure is just plain wrong. I would beg to differ,
sometimes HTPS is more insecure than HTTP: think of Hearthbleed bug that made
servers with HTTPS vulnerable or certs that shouldn't be trusted, or the day
when all LetsCrypt users were vulnerable, etc. Also you will loose a lot of
ad-money. Of course Google with their search monopoly wants HTTPS because they
profit from it. It's sad that Mozilla is influenced by some lobbyist. Well
hopefully the popular forks on Linux distros remove that stupid warning label.

~~~
imajes
Why are you going to lose Advertiser money? That's bogus.

Why does Google profit from HTTPS over HTTP?

Amazon.com (HTTP) redirects to (HTTPS), via a 301 - that's _Permanent_
Redirection.

This also isn't Mozilla, but Chrome.

And honestly i don't even know where to begin, but you should look into HSTS,
and the vulnerabilities that exist transitioning between the two modes[1],

as well as looking at the issues (data bleed, etc) that happen with a
http+https web and mixed content.

Finally the bigger issue to ad rev is likely to be cross origin content rather
than https.

and, er, semantically there's a gulf of difference between "Not Secure" and
"Insecure".

Also, arguably, the shift to a https first web is what's helping us shine
light into bad CAs and deeper audits that are finding the esoteric bugs -- so
it's only a good thing, in the long term.

[1]: [http://michael-coates.blogspot.com/2009/02/compromising-
http...](http://michael-coates.blogspot.com/2009/02/compromising-http-to-
https-redirects.html)

~~~
throwaway6845
> Why does Google profit from HTTPS over HTTP?

Because it removes the ability for ISPs to act as a competitor to Google by
injecting ads and profiling customer browsing.

You may not like that ISPs have done that (I don't) but it's competition for
Google, and removing it is therefore good for Google's profits.

------
webwanderings
This latest upgrade of Chrome uses a lot more memory on my Win7. I run 5 tabs
and I see 10 chrome.exe running processes. WTF and why?

EDIT: I take the above comment back. The chrome.exe processes match with the
process running in the Chrome's Task Manager. I stand corrected.

However, I think there's something new about the latest upgrade. The interface
looks heavy and different. This is the same upgrade which has removed the
green colored SSL identifier in the URL bar.

~~~
Klathmon
This has been like this since before chrome version 1.0

Chrome uses a multi-process architecture. So you have a process for the
"browser", a process for each extension installed, a process for each tab, a
process for the GPU renderer, processes for if it's pre loading a page in the
background, etc...

Many of them share memory.

If you want a bunch of details about all of this, press "Shift + escape" while
in chrome and it will open the chrome task manager which shows a bunch of this
and more.

