
Google Will Soon Shame All Websites That Are Unencrypted - devhxinc
http://motherboard.vice.com/read/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https
======
donohoe
Which is hilarious because the reason I can't switch The New Yorker website to
HTTPS is because of ads - which I'm getting from Google DFP which allows non-
secure ad assets.

In short; Google will penalize me because I use Google.

The universe has a sense of humor.

~~~
cryptoz
Similarly, Google claimed they would start penalizing websites that showed
full-page ads for mobile apps instead of showing you the website. But every
single time I try to get to Gmail, or Drive, or Calendar, or _any_ Google
service on the web using a mobile device, I'm shown a full page ad for a
mobile app. Google has been doing this for years, and it seems like it's also
been a year since they said they'd punish all sites that do that. But Gmail
still turns up as #1 in search results for email, so does calendar, etc. It
seems to me that they have whitelisted themselves and choose not to punish any
Google property that breaks the Google rules, despite claiming to do so.

Edit: Typically, when a service tells me "no you can't use this service until
you view a full page ad" I just give up and not bother continuing to the
service. But the same is not true for Google. I reluctantly click through the
full page ad every single time. It's incredibly annoying that I let them get
away with this and still use the services. They are so outrageously arrogant
about it and it bothers me greatly, but still, I don't change.

Edit 2:

Going to calendar.google.com:
[http://i.imgur.com/fNRhhYx.png](http://i.imgur.com/fNRhhYx.png)

First results for searching 'calendar':
[http://i.imgur.com/l3A5Wlh.png](http://i.imgur.com/l3A5Wlh.png)

~~~
magicalist
> _First results for searching 'calendar':_
> [http://i.imgur.com/l3A5Wlh.png](http://i.imgur.com/l3A5Wlh.png)

Well in your screenshot it seems like you scrolled down on the "calendar"
search results. I get some other random thing ahead of Google Calendar, in
incognito or not.

It is really annoying (I too hate those things, I would have installed the app
if I wanted the app), but the click through thing only happens once in my
testing. Are you clearing your cookies regularly?

~~~
airswimmer
How about using a software to get rid of google ads?

I can erase google ads from DNS level. Users can never reach any google ad at
all.

What you think?

~~~
psykovsky
Adaway was already invented ;)

------
userbinator
The article title really, _really_ needs an extra word: "Chrome", between
"Google" and "Will". At first glance I thought it would be about the search
engine, which would be a very disturbing thought indeed; it's already hard
enough to find the older, highly informative and friendly sites --- which
often are plain HTTP.

Nevertheless, quite convincing security arguments aside, I feel this also has
a very authoritarian side to it: they are effectively saying that your site,
if it is not given a "stamp of approval" by having a certificate signed by
some central group of authorities, is worthless. Since CAs also have the power
to revoke certificates, enforced HTTPS makes it easier to censor, control, and
manipulate what content on the Web users can access, which I certainly am
highly opposed to. I can see the use-case for site like banks' and other
institutions which are already centralised, but I don't think such control
over the Web in general should be given to these certificate authorities.

With plain HTTP, content can be MITM'd and there won't be much privacy, but it
seems to me that getting a CA to revoke a certificate is much easier than
trying to block a site (or sites) by other means, and once HTTPS is enforced
strongly by browsers, would be a very effective means of censorship. Thus I
find it ironic that the article mentions "repressive government" and "censor
information" \--- HTTPS conceivably gives _more_ power to the former to do the
latter, and this is very much not the "open web" but the centralised, closed
web that needs approval from authorities for people to publish their content
in.

There's a clear freedom/security tradeoff here, and given what CAs and other
institutions in a position of trust have done in the past with their power,
I'm not so convinced the security is worth giving up that freedom after all...

~~~
nitrogen
What we really need is opportunistic unauthenticated encryption with key
pinning as a fallback between CA-signed https and plain http. Beating mass
passive snooping is worthwhile even if MITM is still a risk.

~~~
nickik
The Fenrir project does something like this. They first establish a encrypted
connection and then you can authenticate, or not. The authentication can also
be federated.

Its pretty cool, but its not production ready.

The GNUNet has multible layers and do bottum up encryption on the lower
levels.

------
callmeed
Consider this:

\- Squarespace doesn't support SSL (other than on their ecommerce checkout
pages) [1]

\- Weebly only allows it on their $25/mo business plan [2]

\- Wordpress.com doesn't support SSL for sites with custom domains [3]

\- If you've never experienced the process of requesting, purchasing, and then
installing an SSL certificate using a hosting control panel like Plesk or
cPanel, let me tell you–it's a nightmare.

All that to say, this is an interesting development that will leave a large %
of small business websites with a red mark in their browser.

[1] [https://support.squarespace.com/hc/en-
us/articles/205815898-...](https://support.squarespace.com/hc/en-
us/articles/205815898-Does-Squarespace-support-SSL-access-)

[2] [http://www.weebly.com/pricing](http://www.weebly.com/pricing)

[3] [https://en.forums.wordpress.com/topic/support-for-https-
for-...](https://en.forums.wordpress.com/topic/support-for-https-for-custom-
domain)

~~~
icebraining
Then maybe those platforms will finally implement it. In any case, there's an
alternative: putting Cloudflare in front of the site. In fact, Google shows me
a guide to do so when I search for "squarespace ssl".

Of course, that's hardly as secure as end-to-end HTTPS, but still, I trust the
path between CF and SquareSpace much more than between the user's browser and
SquareSpace.

~~~
lambau
Please do not put Cloudflare in front of your site. It makes it impossible for
tor and VPN users to view your site since they have to solve an impossible
captcha to even see the static content.

~~~
mintplant
It's possible to turn off security in the CloudFlare control panel. I think
the bigger issue is that CloudFlare has become a single point of interception
for MITM'ing huge portions of web traffic.

~~~
ryanlol
I'm not sure, but I think CloudFlare will still hit Tor users with
(unsolvable) captchas even with the lowest security settings.

But yeah, this NSA slide is extremely relevant to cloudflare:
[http://cdn01.androidauthority.net/wp-
content/uploads/2014/06...](http://cdn01.androidauthority.net/wp-
content/uploads/2014/06/SSL-Added-and-Removed-Here.jpg)

~~~
lambau
> I think CloudFlare will still hit Tor users with (unsolvable) captchas even
> with the lowest security settings.

That is correct. I have not been able to get passed a Cloudflare captcha over
tor for any website.

------
Someone1234
This is how it always should have been.

It was mind boggling that mixed content was "insecure" but HTTP was "secure."
HTTP is and always has been insecure and should be marked as such.

I know there are a few people who will moan and groan about how overkill HTTPS
is, but this isn't about banning HTTP it is just about reminding users that
they shouldn't be entering sensitive information into a HTTP site.

Even phishing sites should be DV secure.

~~~
mhurron
HTTP was never marked as secure.

Mixed content was marked insecure because there were assets on the page that
might not be from where you think they were from. It was an indicator that the
little https lock in the URL bar wasn't telling you the whole story.

~~~
ethbro
I think this is at the core of Google's thinking on this: unless presented
with a negative, users' assumptions are that they're secure.

Which is fair, given that I bet you'd get about a 5% or less recognition rate
if you polled a random sampling of people on whether they could define "HTTPS"
/ "SSL" / "TLS" / "That lock thingie" to any degree of accuracy.

A server shouldn't have the opportunity to serve an insecure connection to the
user without the user being made explicitly aware of that fact.

------
dude01
Sounds good. I wonder when Google Cloud Storage will start supporting https on
static websites hosted through them:

[https://cloud.google.com/storage/docs/website-
configuration?...](https://cloud.google.com/storage/docs/website-
configuration?hl=en)

If they don't then they're not keeping up with hosting on Amazon's S3, which
does support it.

~~~
mikecb
Similar (very, since appengine static files are served from GCS), is to write
a "python" appengine yaml file that only serves the static content with
secure: always.

------
gesman
Google should offer stupid SSL certificates either for free or for $1/yr.

Perhaps at least to customers of Google domains. I won't mind switching from
namecheap to Google domain in latter case.

~~~
ergothus
Getting a Google domain means giving up getting new features from Google :(
(pauses to clean up bitterness)

~~~
notatoad
No, it does not. Signing up for google apps and choosing to use the google
apps account as your primary google user account causes you to get new
features on a delayed schedule.

You can get a domain through google without switching your google identity to
it. You can also sign up for google apps on a non-google domain. google
domains and google apps are not the same thing.

~~~
bad_user
On Google Apps there are features that have been deployed years ago for
regular accounts and that are still not available for Google Apps customers.

The one feature missing and that was painful for me were Contacts photos with
a resolution higher than 96x96 pixels. On a latest generation Android with
good resolution it sucks and I would have preferred if Contacts photos weren't
synchronized at all. I ended up switching to a CardDAV provider and in the end
I gave up on Google Apps for other reasons as well. And for the record, Google
accounts had this resolution increased in 2012 ;-)

~~~
kamaln7
Hold on. Are you saying that that's why Android's Contacts keeps resizing all
the photos to like 4x4px? Wow, I've tried everything I could find on Google
but it never crossed my mind that it would be related to Google Apps. Thanks
so much!

------
mholt
In the hopes that it will help spread adoption of HTTPS, I wrote a web server
that serves your sites over HTTPS by default, using Let's Encrypt:
[https://caddyserver.com](https://caddyserver.com) \- It also redirects HTTP
-> HTTPS.[1]

There's a lot of misinformation out there about certificates and HTTPS, but
don't let it stop you from encrypting your site. Regardless of Google's move,
there is no excuse for any site not to be served encrypted anymore.

[1] Here's a 30s demo:
[https://www.youtube.com/watch?v=nk4EWHvvZtI](https://www.youtube.com/watch?v=nk4EWHvvZtI)

~~~
plasticxme
This is an awkward argument. One of my sites documents how to configure
servers, for example. What excuse is there that something like that needs to
be encrypted?

The most legitimate reason I've heard is for privacy. I don't believe the
gov't is going to lock someone up for learning how to serve web pages.

~~~
geofft
Integrity protection. There are a lot of ways to instruct someone to configure
their web server in a way that is subtly insecure, not to mention attacks like
[http://thejh.net/misc/website-terminal-copy-
paste](http://thejh.net/misc/website-terminal-copy-paste)

It'd be slightly nice if we were able to have integrity-protected HTTP without
encryption (lower overhead, easier debugging with packet dumps), but the
advantages are minimal (ciphers are not really the overhead, SSLKEYLOGFILE is
a thing) and it's a lot of complexity to the web platform, which is a downside
for web developers like you and me: the rules for mixed content between HTTP,
HTTPI, and HTTPS are going to be much more involved and confusing.

~~~
Franciscouzo
You can already send unecrypted authenticated data with HTTPS.

~~~
geofft
Via one of the NULL-cipher suites? That's a somewhat expansive definition of
"can" and "HTTPS," since most if not all browsers are unwilling to negotiate
any of those suites. Indeed, most SSL libraries make it hard to use those
suites: for instance, OpenSSL says (`man ciphers`), "Because these offer no
encryption at all and are a security risk they are disabled unless explicitly
included."

Which makes sense, since they'd have the exact same problems as an explicit
HTTPI protocol, just even more confusing: you'd want to not send things like
secure cookies across those ciphers, you'd have to handle mixed content with
actual-HTTPS carefully, etc.

------
oliv__
Why do we have to go through this whole SSL certificates thing and can't just
have a simple, automatically secure, I-do-nothing-and-my-website-is-secure
protocol?

Seriously though. If secure is the default from now on, why can't it actually
be the default?

~~~
x0
Seriously this. I don't see why encryption and website verification have been
wrapped up in the same thing (SSL certs). They're two different things.
Encryption should be free, automatic and default.

~~~
schoen
If you don't have a way to confirm that the key you're seeing from the other
site is right, you're inherently vulnerable to a man-in-the-middle attack
which removes the benefits of the encryption against the attacker.

[https://en.wikipedia.org/wiki/Man-in-the-
middle_attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)

httpS://en.wikipedia.org/wiki/Zooko's_triangle

It's not clear that the certificate authority system was or is the best
solution to this problem, but it is a problem that calls for _some_ solution.
In the case of Domain Validation, we only try to confirm that the key is
appropriate to use with the domain name, which is the smallest possible kind
of confirmation that can be done to address the crypto problem. There's no
attempt to validate or verify anything else about the site.

~~~
cellularmitosis
However, having one and not the other isn't totally useless.

Having the browser be able to track and tell me that "Though we aren't sure
this is actually google.com, we do know that the exact same cert has been used
the last 50 times you visited this website" is something I'd consider to be
useful. (Actually, telling me if it changes would be the useful bit).

That would be at least be useful for self-signed certs (though those aren't
really needed in light of Let's Encrypt...)

~~~
rspeer
> (Actually, telling me if it changes would be the useful bit).

I'm curious. Has anyone ever encountered that scary warning you get when an
SSH host key changes, and thought "oh man, I'm getting MITMed, I'd better not
connect to this server!", instead of thinking "oh right, I guess they
reconfigured the server, now what command do I type to make the warning go
away"?

~~~
tomjen3
I have. Usually it's because i reconfigured the server, but I am ultra
paranoid. Most people don't care, but I would expect sysadmins to do so. And
who else should login with ssh?

------
shostack
Is there a strategic business reason for this on Google's part other than a
safer web is better for all? I don't doubt that a more secure web is better
for everyone, I'm just more curious about the business drivers of this from
their perspective.

The reason I'm wondering is because with AMP, there seems to be a clear
strategic benefit from having all of that ad serving data running through them
even if the advertisers and publishers are not using the DoubleClick stack or
Google Analytics.

By bringing this to market from the standpoint of "improving" the mess
publishers have brought upon themselves and speeding everything up, there's
definitely a clear win for consumers here. That said, it leaves the door open
for something similar to mobilepocolypse where Google updated their ranking
signals on mobile to significantly favor mobile-friendly sites. I could easily
see this going a similar route where it is a suggestion...until its not
because if you don't implement it you'll lose rankings and revenue (and
coincidentally feed Google all of your ad serving data in the process).

To be clear, I don't knock them for taking this approach, because if it works
it is a very smart business move that will be beneficial to a lot of parties
(not just Google). Just looking for other insights into the business strategy
behind something like pushing for encryption, and AMP.

~~~
jimrandomh
> Is there a strategic business reason for this on Google's part other than a
> safer web is better for all?

The two common reasons for MitM are spying and inserting/replacing
advertisements. The latter is stealing from Google, so they want to stop it
before it grows too common.

~~~
kuschku
We can only wonder how long it will be until Google starts openly advertising
and buying newspaper articles against that new ad-replacing browser.

------
bhartzer
For Google, it’s not just about providing a secure environment and secure
websites. In fact, Google actually has a monetary incentive to get as many
websites to move over to HTTPs as possible: convincing website owners to move
to HTTPs will help get rid of competing ad networks.

~~~
aembleton
How does it get rid of competing ad networks? Does Google have a monopoly on
serving ads over HTTPS?

~~~
callahad
It means your internet provider can't inject ads or profile you based on the
content of the sites that you visit. Comcast, AT&T, and Verizon have all done
similar: [https://certsimple.com/blog/ssl-why-do-i-need-it#4-not-
havin...](https://certsimple.com/blog/ssl-why-do-i-need-it#4-not-having-your-
content-modified-by-carriers)

~~~
eyuelt
Sure they can. Your ISP can easily MitM you.

~~~
CydeWeys
Not without throwing cert errors on every site I visit.

The only way they can MITM me is if they compromise my PC as well and install
their root CA.

~~~
toyg
... or rather get an intermediate certificate from one of the umpteen root CAs
your operating system embeds by default.

Is VeriSign going to refuse a certificate to AT&T?

~~~
snowwrestler
Verisign will happily issue a certificate to AT&T for a domain that AT&T
controls.

Verisign will not issue a certificate to AT&T for google.com--no matter how
nicely AT&T asks.

~~~
geofft
Yes, and furthermore there's a very good reason to believe that this claim is
true: as soon as they do, every copy of Chrome behind AT&T's network will go
and snitch to Google, who will promptly investigate and get Verisign in deep
trouble.

Here's what happened when Symantec issued fake Google certificates last year:

[https://googleonlinesecurity.blogspot.com/2015/09/improved-d...](https://googleonlinesecurity.blogspot.com/2015/09/improved-
digital-certificate-security.html)

[https://googleonlinesecurity.blogspot.com/2015/10/sustaining...](https://googleonlinesecurity.blogspot.com/2015/10/sustaining-
digital-certificate-security.html)

"Therefore we are firstly going to require that as of June 1st, 2016, all
certificates issued by Symantec itself will be required to support Certificate
Transparency. After this date, certificates newly issued by Symantec that do
not conform to the Chromium Certificate Transparency policy may result in
[annoying certificate warnings, just like self-signed certs]."

And that was just the work of a couple of employees who were inappropriately
testing their issuance system and weren't even intending to attack anything.
They got fired, which I expect is also a big part of why Google's response was
so _light_.

[http://www.symantec.com/connect/blogs/tough-day-
leaders](http://www.symantec.com/connect/blogs/tough-day-leaders)

------
Zikes
I think it's pretty funny that on the HN front page right now is a NYTimes
article from the company's Google beat reporter about how trying to interview
Larry Page is "emasculating" and then this announcement is accompanied by an
image "shaming" the NYTimes web site for being unencrypted.

As to the feature itself, I don't think it's a big deal at all. We all know
that the average internet denizen doesn't understand HTTPS at all and would
just as likely ignore it as anything. The only people that would see and
understand this new red X for what it represents would know that it doesn't
really matter that the lolcat meme they just downloaded came through an
unsecured channel.

~~~
civilian
I work for a SaaS company, we absolutely have customers who email us
complaining about putting credit cards in a page served over http.

~~~
Zikes
Certainly, and I would be one of them. I'm not saying nobody does care or that
nobody should, only that enough people don't care enough to make this "red X
of shame" that shameful, really.

Chrome and Firefox have both had to take extreme measures for very similar
things, such as web sites using expired (or even unvalidated/spoofed) SSL
certificates. Google even reported that using a giant red page with warning
labels didn't stop people from clicking through!

~~~
civilian
Right, and I guess I meant to imply that it is some of the unwashed non-elite
masses that notice that stuff. Our product is for people who are bad at
software and want an easier way to do task X, but they still know to look for
the green lock. I don't have strong data but I'd just say-- don't
underestimate the web knowledge of people who are mostly making cat pictures.

------
BogusIKnow
Main problem still is Google: They consider HTTPS and HTTP links the same.
When switching a site to HTTPS you lose all your incoming links. Redirects
only transfer a small amount of juice. You're toast.

We tried migrating several times to HTTPS only, every time got a huge penalty
from Google.

So Google is the main driver for HTTP websites.

~~~
gabemart
> They consider HTTPS and HTTP links the same. When switching a site to HTTPS
> you lose all your incoming links.

Do you mean that they _don 't_ consider HTTPS and HTTP the same? Otherwise, I
don't understand your point here.

~~~
BogusIKnow
You're right.

------
Theodores
Just enabled Chrome to show the little crosses by default for
[http://](http://) and I already like having this showing. If you wish to be
an early adopter go to:

chrome://flags/#mark-non-secure-as

It is good to see how sites that matter are mostly [https://](https://)
already for me. The [http://](http://) tabs I have open such as this article
actually are insecure when you think about the amount of trackers on them, so
the 'x' is very apt.

------
tomjen3
They should do something useful for the web and remove most if not all the
current root certificates. There are so many places that have what is
essentially a master key to the internet - and that master key is only going
to be more important as more and more sites become SSL.

------
SanderMak
So is there already a solution for https on Github Pages with a custom domain?

~~~
tdkl
Stumbled upon Kloudsec here on HN couple days ago [1] and gave it a go. The
dashboard is a bit clunky where you kinda have to figure out what to do, but
HTTPS works without needing to move the DNS to them, as in case of Cloudflare
(which costs 20$ when moving from Gandi).

Basically register account, enter your domain, update your DNS records with an
A (replacing the Github pages IP) and TXT record (for verification).

While the change in DNS was in couple minutes on Gandi, Kloudsec DNS took an
hour or two to register the change. After that, you go in the "Security
plugin" and enable it. If you're using an apex domain, you can remove the www.
HTTPS request, since you won't get the cert for that (if you do have an apex
domain then you probably know about the CNAME trick on Pages, unless your DNS
provider supports ANAME or ALIAS records for the apex domain - Gandi doesn't).
It took couple hours again to get the cert.

When it's done click on the "Settings" cog icon for the desired HTTPS domain
and enable HTTP-> HTTPS redirect and HTTPS rewrite, then you're set.

[1] [https://kloudsec.com](https://kloudsec.com)

~~~
voyou
I'm not sure what you mean about Gandi charging $20 to move the DNS to
Cloudflare? I'm using Cloudflare to add HTTPS to a website on a domain
registered with Gandi, and it hasn't cost me anything above the usual domain
registration fee.

~~~
tdkl
Hm yeah, after reviewing the transfer policies, I guess I mistakenly thought
the price for transfer TO Gandi stands for transfer FROM as well. It's still a
bit more hassle then what Kloudsec offers.

------
dorianm
Yes! Funnily enough, the site this story is hosted on is using HTTP.

~~~
dawnerd
[https://motherboard.vice.com/read/google-will-soon-shame-
all...](https://motherboard.vice.com/read/google-will-soon-shame-all-websites-
that-are-unencrypted-chrome-https)

They should have it force https.

------
drivingmenuts
All of this raises the question: why does the new default state require
action, while the non-default state requires none?

Is that more or less bass-ackwards?

------
ninjakeyboard
Should static content be encrypted over https? I think it's fair for chrome to
call out with an x as I've literally seen local lunch joints take orders with
credit card info over http but to serve mostly static pages like the new
yorker over http only means that the user's privacy is compromised in that
people can see what you're reading - does that warrant down ranking searches?
I'm just curious - I work mostly on platforms so I'm not too aware of all of
the incentives for trying to move everyone to https as it's not my problem
domain necessarily.

~~~
Spooky23
Because mobile carriers are given broad discretion to do whatever they want to
do to your traffic.

They cheerfully modify content, and have built infrastructure to do it even
more.

~~~
ninjakeyboard
hmm ya this is a good point.

------
jrbapna
How will this impact page-speed?

I recall switching the product pages of an e-comm site, which had up to 50
small images per page, from https to http and the change very significantly
increased page load speed for the end user

~~~
srj
I'll guess that the browser opened several connections to fetch all of the
content (to work around broken http/1.1 pipelining) and needed to complete
many tls handshakes. http2 probably would have done a better job.

------
darkhorn
Several weeks ago I have installed certificate to my web site on NGINX and it
wasn't hard. It was fun to do. Also I got A+ from Qualys SSL Labs. What I mean
is it is easy to deploy an HTTPS site.

~~~
plasticxme
Deploying TLS in simple environments isn't overly complicated. It's just cost
prohibitive.

------
frik
HTTP + HTTPS is fine

HTTPS for SaaS and e-commerce web apps is fine

HTTP for normal websites is okay (for me, I have no hidden agenda)

HTTPS-only for normal websites is silly, why not offer HTTP too? Every request
is unique, no internet anonymity.

~~~
agildehaus
Why is HTTPS-only for normal websites silly? It ensures the page was not
tampered with enroute.

~~~
frik
Why not HTTP + HTTPS? Let the user decide. HTTPS _-only_ is silly for _normal_
websites. Visitors from cooperate networks or some countries would say, your
second sentense doesn't hold in the real world.

------
coder-otherstuf
While I am a fan of HTTPS everywhere, there are just some use cases that are
not feasible for HTTPS.

One edge case I am familiar with is a case where a webapp is used to setup a
headless device (like a wireless repeater or hub for example). In this
scenario, a user loads the page from a web server, the page instructs the user
to put the device in a mode that it acts as a WiFi access point, the user then
changes the access point of their machine, the page can now make AJAX requests
to the device access point which is also acting as a server allowing the user
to POST things like WiFi credentials for the device to use.

In this edge case one of two things need to happen, either the original page
must be served as HTTP since no CA will issue you a cert that can be served by
such a device. Or the device must act as more than a simple API server and
would have to serve HTML pages which would get linked to by the original page.
While the second solution is fine to get HTTPS everywhere (with the exception
of while connected to the device), it means that the development and
improvement of setup UI is tied to device firmware updates as opposed to speed
and flexibility of web development.

------
wbillingsley
Surely it could be a lot easier...

Everyone already has a known public third party authority -- their domain
registrar. Surely the browsers could come up with some protocol where you
generate your own keypair, register the public key with the registrar and keep
the private key on the server.

Then it could work pretty much like SSH, but with the browser doing out-of-
band public key checking. Rather than needing a certificate chain, the browser
just checks the server's public key matches the published one. If ok, happy to
encrypt. If not, wave flags, and yell "spoof".

Verifying the registrar isn't a fly-by-night can be as complicated as needs
be, but that way the registrar (who already gets paid to register the domain)
does the complex hassle, while the ordinary domain-buyer just has to keep
their server's public key up-to-date with the registrar (ie, fill in one web
form at the time you register the domain or whenever you change the server
key).

But alas it is not so at the moment. Instead, the current process puts hassle
onto millions of individual domain-owners, while keeping life easy for the few
(paid) certifying authorities. And then we wonder why so few people want to do
it.

~~~
kuschku
Even better.

Put the public key in DNS, auth the DNS.

~~~
wbillingsley
I thought about that, but there's so many DNS caches out there with potential
bugs to make them insecure and poisonable.

But a set of public keys from the registrar is "content". It's small, so they
could just have a server or two to handle it. (But if load/latency was an
issue, well everyone's pretty good at content-distribution networks these
days...)

~~~
kuschku
Well, if someone can manipulate your DNS, you have other issues than your SSL
certificate anyway.

Ideally, DNS should be signed by your registrar.

------
tobbyb
I feel a bit of dissonance on hn on the issue of https. On issues of
surveillance and spying the responses are often measured and there is
generally a balanced debate, and yet on ssl suddenly its a matter of extreme
urgency with strident positions backed up by references to mitm, spying and
isp injected ads.

This is not as urgent a matter as some here tend to make it, better to resolve
it properly than rush into half baked solutions like Google shaming websites.
Why should a private company have the ability to shame websites and drive
decisions a certain direction without any consultative process and
accountability. Surely these are decisions for industry groups and wide
consensus, and not individual corporates driven by self interest.

Corporates routinely mitm ssl traffic and no one is shaming them or the
equipment makers for that, so ssl and mitm is hardly going to be problem for
state actors. For protection against less influential actors, banks and those
who process sensitive data have been on https for a long time now so where is
this urgency and the need to take action coming from?

Everyone agrees security is good but the mechanism to enable this cannot be
given up to browser makers and CAs. This is a complete loss of end user
control and a significant step back from the open net that cannot just be
brushed aside.

Not everyone needs https and for ads injections the pressure should be on ISPs
to stop the illegal behavior. Why can't we shame ISPs instead of forcing all
websites to https?

Other solutions like signing content that empowers individuals rather than
corporates and vested interests should be explored. The same browser makers
went ahead and arbitrarily started flashing grave warnings on self signed
certs without any consultative process or accountability.

------
bphogan
Why don't I like this?

I don't think it's HTTPS.... I think I don't like that one company has this
much power over the web.

This seems awfully familiar...

~~~
sdrothrock
I don't like this because I've always thought that HTTPS shouldn't be a
mandatory baseline. It doesn't make a whole lot of sense to me that a random
website with no financial transactions or anything should require HTTPS.
[Edit: And thus, it makes less sense to me that the site should be penalized
by anyone for NOT having it.]

"Ah, yes. Bob's Trivia Emporium has HTTPS. I know this is really Bob's site
and that the data is from his site."

If anyone has compelling arguments to the contrary, I'm open to hearing them.

~~~
frankchn
HTTPS assures the integrity of the data transferred is from the origin domain,
so it prevents your ISP from injecting additional ads into tour site, which
some ISPs like to do [1].

[1]: [http://arstechnica.com/tech-policy/2014/09/why-comcasts-
java...](http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-
ad-injections-threaten-security-net-neutrality/)

~~~
sdrothrock
That doesn't convince me; it's like saying every Tom, Dick, and Harry should
get encrypted phones because Verizon has the capability to tap into
conversations. The onus should be on the provider, not the customer.

~~~
nickik
You dont think that normal user should use encrypted phone sevices? Are you
serious?

------
afarrell
There are occasionally times when I want to suffer a MITM attack. For example,
when I am on an airplane, at a hotel, or basically any other time I have to
fill out a webform to get online. Perhaps those forms should not exist, but
until they don't, I hope [http://xkcd.com](http://xkcd.com) continues to work.

~~~
schoen
Google has a service for this: [https://www.chromium.org/chromium-
os/chromiumos-design-docs/...](https://www.chromium.org/chromium-
os/chromiumos-design-docs/network-portal-detection)

------
ksk
I wonder if this will reduce malware that injects advertising into users'
browser sessions. Seems like a win-win, but I don't trust Google at all. They
want all private data un-encrypted and available for their own
analysis/mining/auction when it comes to their own servers and services.

------
pjc50
So is there a lets encrypt solution for shared-hosting systems?

~~~
pfg
The solution for shared hosting environments is for your provider to integrate
with Let's Encrypt (or any other free CA that might pop up in the future).

Once this change goes through, providers will be forced to either do that or
(if they think forcing users to keep paying for SSL, even though it's de-facto
mandatory) watch their customers move somewhere else. There's plenty of
competition out there, and a lot of them already support Let's Encrypt[1].

[1]: [https://github.com/letsencrypt/letsencrypt/wiki/Web-
Hosting-...](https://github.com/letsencrypt/letsencrypt/wiki/Web-Hosting-
Supporting-LE)

------
SFjulie1
Yes, shame all libraries/swimming pools giving their schedule online without
HTTPS. Shame gutenberg project, the documentations for OS, code, your washing
machine.

Why would money from libraries gutenberg project, NGOs informations go to more
expansive OPEX for web hosting when an information is clearly designed and OK
to be public?

And does not require adds or payment.

Google has some _godwin point_ very authoritative views on the internet and
the protocols that make me dislike them.

Especially that their business model it is to not pay transit for distributing
their contents. Basically every fucking internet users pay the 95th percentile
transit to google products even if they don't watch videos on youtube, don't
use gmail or else.

These people are like ... catholic priests. Do as I say, not as I act and be
good members of the community.

~~~
geofft
What additional money is needed to implement HTTPS? It's like an afternoon of
a sysadmin's time; it doesn't require any more opex.

If you have a favorite library or NGO that doesn't support HTTPS for lack of
funding, I am personally happy to donate an afternoon's of a sysadmin's wages
to them. (Or to set it up for them, honestly.)

Project Gutenberg is already over HTTPS, so I'm not sure what you mean by
that. If you think they were strongarmed by Google into it, instead of having
decided this long ago as a simple and obvious step for the good of their
mission, a reference for that would help inform the discussion.

~~~
SFjulie1
buying a certificate and changing it yourself. So it costs minimum price a
certificate, and at least one person competent enough.

And competence in terms of spending is way more than the certificate.

Outsourcing security without knowledge is praying for being abused.

So sometimes you are better in terms of costs and efficiency without.

And HTTPS cost more for rural users because you cannot cache SSL contents.

So in africa, alaska, yukon, peta ouchnok people with small providers have to
pay a tax.

And it increases also the 95th percentile.

So basically everybody except google will pay for this but it will impact more
the poorest content provider & users.

~~~
geofft
Certificates are free. The required competence is only marginally more than
the required competence of setting up a website, and is rapidly dropping to
zero more. (And _is_ , if your website is hosted by a third-party service,
which is a pretty reasonable approach for the organizations you name.)

I don't understand what you mean by "Outsourcing security without knowledge is
praying for being abused." From your original argument, the website admins
don't care about security, right? So the worst that happens is their setup is
insecure, but their setup was insecure to start with, and the were okay with
that. You aren't _more_ at risk from outsourcing your HTTPS versus just not
doing HTTPS.

I'd be very surprised to hear that people in Alaska are getting their internet
via an HTTP cache. Frankly, I'd also be surprised to hear that people in
Africa are, except possibly for certain mobile internet. I'm curious, where
does this happen?

Even so, and especially for mobile internet, HTTPS isn't a problem. The
provider gives you the phone, so they can control the software, certs, etc. on
it. They can run a caching proxy server that takes "HTTPS" requests in
plaintext, and sends them out over HTTPS if they can't be satisfied from the
cache. (It's pretty easy to configure an HTTP forward proxy this way.)

~~~
SFjulie1
Certificates are free? Some are. Do you trust certificates given without
checking the real identity of the user?

I do not. It has a cost. If you do not check you have the perfect tool for a
MITM.

Then is https more expensive than http?

Of course you idiot. Have you never seen your CPU burn under https? With TLS
the load is on the first connection. Meaning it is around x% (x said to be 1
by google) for long sessions IF and only IF you have a costly engineer
optimizing your stack. And I know by experience that google cipher suite are
sometimes close to be ridicusly weak in order to achieve this. (I saw an RC4
while playing with gmail). And that is servers side. Add the client side.

So what about no "engineer". What about an SSL2.0 cipher suite having RC4 MD5
... and all the default weak settings recommended you can see on the internet?

Well, the illusion of security is no security. the S of https is for security.
Having a tag saying I am secure if any government or criminal organisation can
break your ciphering in a matter of seconds is no actual security. And it
defeats the purpose of TRUST granted by security.

Then way pay the extra x% of https in this case?

Oh! I just read your last paragraph.

Can someone explain to this person why HTTPS cannot be cached? Oh! It can it :
has been sold to Tunisia by MS in 2007, France to lybia circa 2005, China is
doing it ... for intercepting and deciphering citizens conversation.

Caching HTTPS is basically doing a Man In The Middle attack. It requires a
"joker" certificate nicely given by a root authority. Doing so (as microsoft
did) normaly induce "the death penalty" of security firms. MS is alive, hence
anyway we cannot trust https ... since snowden revelations.

The proxy would still have to do the handshake anyway to have the https => cpu
load.

The premise of security are trust. https nowadays is a costly joke.

For the record operators especially when IP routing goes through shared tunnel
of collects (3G) have been traditionnaly using a protocol called WCCP to cache
transparently your http content. And 4G is deployed substantially in USA &
wealthy European countries, but not everywhere.

So even if you don't have a proxy your operator may.

And if you think all USA is at 1Mb/sec for 50$/months read this
[http://seclists.org/nanog/2015/Oct/337](http://seclists.org/nanog/2015/Oct/337)

Last and least : I worked in an ISP 10 years ago. One of the datacenter was 5%
of france global traffic, the electricity used was as much as a city of 40K
inhabitants.

It makes internet as an industry the biggest user of fossil energies.
According to my approximation we should be around 2%[+1%?] of the global
national consumption. Very near transport industry (plane + trucks). And https
will not help.

So I see no other arguments for https than being sheeps.

~~~
geofft
> Certificates are free? Some are. Do you trust certificates given without
> checking the real identity of the user? I do not. It has a cost. If you do
> not check you have the perfect tool for a MITM.

But you just said that HTTP was fine, right? You can MITM plaintext HTTP too,
so I don't understand why that's a problem for HTTPS to be (potentially)
MITMable.

> Of course you idiot.

I have stopped reading here. Please read
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
CM30
So what would this mean for web development agencies and the likes, who've
made hundreds of thousands of websites (most without SSL) and would now be
forced to convert them all to use https?

How many clients would be willing to pay to cover some of the time wasted
doing that?

And how about the potential SEO impact? I mean, Google says switching to https
shouldn't affect things, but I've seen tons of sites lose rankings after a
change.

Okay, using https is a good thing and all, but the inconvenience caused by
having to make this change could be massive.

------
mderazon
It's very surprising that Google doesn't sell certificates on Google Domains
or offer any ssl support in GCE storage stack and yet they are going so strong
after web encryption. What about setting an example ?

------
shurcooL
Sounds good to me, thanks to Let's Encrypt. All my personal sites are now on
https and HTTP/2 (thanks to Go 1.6). I don't use ads so I have nothing
blocking me from https.

The only situation where I still want to use HTTP is one page I serve, which
uses websockets, and I don't want to use secure websockets, but that's the
only exception.

I'm glad to be in this boat. Once again, it's mostly thanks to Let's Encrypt
being awesome, and I'm thankful to it.

------
tacos
Cue the sound of 100,000 static-hosted S3 bloggers grabbing their free Amazon
SSL cert and setting up CloudFront. And man that AWS console sure is wonky.

~~~
chatmasta
I tried setting up SSL with Cloudfront yesterday and it was a complete mess.
The validation method is sending an email to the domain contacts as listed in
whois. So if you have whois privacy enabled, you cannot receive the email and
therefore cannot setup the cert.

This is definitely a bug, because the system supposed to also send emails to
admin@domain.com, hostmaster@domain.com, and a few others. With whois privacy
enabled, I never received _any_ of those emails.

Even _with_ whois privacy, you are supposed to be able to receive an email via
the privacy registrar's proxy email... but Amazon parses it incorrectly and
ends up sending the email to legal@whoisproxy.com

I'm not the only one:

[https://forums.aws.amazon.com/thread.jspa?messageID=698280&t...](https://forums.aws.amazon.com/thread.jspa?messageID=698280&tstart=0)

[https://forums.aws.amazon.com/ann.jspa?annID=3510](https://forums.aws.amazon.com/ann.jspa?annID=3510)

------
5ilv3r
This is stupid. Making https a requirement will break most web pages on
hardware older than 2005 or so. This sucks for anyone without money.

~~~
icebraining
It doesn't make HTTPS a requirement; it just shows a red lock.

------
drawkbox
Hopefully costs for certificates will come down to encourage it as well.
Services like letsencrypt can help.

~~~
conanbatt
Supply and demand would dictate otherwise

~~~
freehunter
Well it's not like certs are a limited quantity; they take no time to produce,
no limited resources to produce, and no manpower to produce. Supply and demand
works when demand outstrips supply, so the price goes up to put downward
pressure on the demand. There's no possible way for demand to outstrip supply
of certificates, so prices shouldn't go up.

------
artichokeheart
I think one of the big problems with unencrypted websites is shared hosting,
who refuse to use SNI certificates (often because it would require upgrading
their infrastructure). So users have to pay for a static IP which effectively
doubles their hosting costs so most don't bother.

~~~
threesixandnine
If they don't bother why should people bother to pay for their hosting? There
are many, many hosting companies that do bother and I am using one of them.
Had no problem installing Let's Encrypt cert on shared hosting via cPanel
there.

~~~
crisnoble
Who are you using?

~~~
threesixandnine
I am using ASO.

------
xdinomode
My website runs on a vps with NodeJS as the backend. I could easily self sign
a certificate but chrome displays a huge warning to users. How about signing
certificates for free google. Https is easy to implement but the fact that it
costs is bs.

~~~
chipperyman573
LetsEncrypt offers free, automated certificates and is recognised in all major
browsers (IE, Chrome, FF, Safari).
[https://letsencrypt.org/](https://letsencrypt.org/)

~~~
xdinomode
Oh wow I've actually heard of this before thanks for the tip.

------
Nutmog
"mark non-secure origins as non-secure." The name of that option seems to be
chosen to apply a bit of pressure to anyone who sees it. Nothing wrong with
that of course - it's our existing habits of trusting HTTP that are strange.

------
airswimmer
I think 80% of web sites will be labelled as red-unsafe.

SSL layer security is good but sometimes a certificate is expensive and not
free. Suppose that you have 10 domains and not all of them are for SNS, banks
and etc..

At what minimum cost will you purchase a HTTPS certificate?

~~~
pmlnr
nada.

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

~~~
bcg1
Most shared hosting accounts charge extra for a dedicated IP address, both for
setup and on a monthly basis. Don't underestimate how many blogs, churches,
small businesses, etc still use services like that.

To be fair, many of those sites probably ARE insecure, but it seems to be a
little bit overkill to "shame" them for not implementing encryption.

~~~
JoshTriplett
SSL hasn't required a separate IP since Windows XP. And XP no longer has any
security support, so anyone running it has bigger problems.

~~~
bcg1
Guess you're right, fair enough. I still don't agree with putting a scarlet
letter on these types of sites though.

~~~
JoshTriplett
Nothing short of that will get HTTPS adoption to approach 100%. Many people
have commented that it seems odd to complain about broken HTTPS but not about
HTTP; I agree with that. As long as browsers show unencrypted HTTP as
"neutral" rather than "bad", far too many sites simply won't care. This has
been a long and gradual step, but it needs to happen for HTTP to finally go
away.

~~~
airswimmer
HTTPS is rather more secure than what HTTP is. Because it creates a relative
secure tunnel between the client and host. But HTTPS does not mean 100%
secure, it's easy to be hacked by MITM or traffic been spied.

I think that getting rid of HTTP should not be shamed in that way. But google
is planning on doing this thing.

Just as someone said, MITM attackers can switch google ads to others, and I
think this is the reason why Google wants to shame those sites who use Google
Ads and not use HTTPS. Google can make an increasing revenue by this act.

And yet HTTP2 is out, will google shame those sites who only support
HTTP1.0/HTTP1.1 ? I don't think so. Because this has almost nothing to do with
revenue for Google.

~~~
JoshTriplett
> But HTTPS does not mean 100% secure, it's easy to be hacked by MITM or
> traffic been spied.

I don't know what properties you think HTTPS lacks here, but no, HTTPS doesn't
allow "easy" MITM or eavesdropping. If you want to break HTTPS, you either
need to compromise an endpoint, or pressure an accepted certificate authority
to risk destroying their entire business by issuing a fraudulent certificate.

------
ssalat
[https://news.ycombinator.com/item?id=5238164](https://news.ycombinator.com/item?id=5238164)

Still not solved... calm down Google!

~~~
finnn
Use Let's Encrypt to automatically issue a cert valid for each domain?

------
cballard
Is there a good guide on making S3 sites work with SSL?

~~~
adambrenecki
You can use the new AWS Certificate Manager[0] with CloudFront[1], which you
can attach to your S3 bucket. The docs aren't brilliant, though.

[0]: [https://aws.amazon.com/blogs/aws/new-aws-certificate-
manager...](https://aws.amazon.com/blogs/aws/new-aws-certificate-manager-
deploy-ssltls-based-apps-on-aws/) [1]:
[http://docs.aws.amazon.com/acm/latest/userguide/gs.html](http://docs.aws.amazon.com/acm/latest/userguide/gs.html)

------
Mz
So, can someone tell me: Will they be assholes and shame BlogSpot sites (i.e.
Google's own service)? Or will it be upgraded or something?

------
siquick
I used Cloudflare's free SSL - is this enough?

[https://www.soundshelter.net](https://www.soundshelter.net)

~~~
arikrak
Yes. Google can't know what happens between Cloudflare and your server.
(Communication there is also less likely to be intercepted as between the
user's browser and the internet.)

~~~
siquick
Good to know - thanks

------
akorchemniy
This might have the unintended consequence of causing people to go numb to the
"false positive"

------
protomyth
Is there a checklist somewhere that specifies each of the things that Google
requires / forbids?

------
bjblazkowicz
So what about the overhead of https?

~~~
geofft
For the last few years, effectively zero.

[https://istlsfastyet.com/](https://istlsfastyet.com/)

[https://www.maxcdn.com/blog/ssl-performance-
myth/](https://www.maxcdn.com/blog/ssl-performance-myth/)

[https://www.imperialviolet.org/2010/06/25/overclocking-
ssl.h...](https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html)

Not to mention that if you use CloudFlare just to get a free SSL certificate
out of them, you're also getting a CDN, so the performance overhead is
_negative_.

~~~
drdaeman
I thought the same, but reality isn't that nice. Got this response:
[https://news.ycombinator.com/item?id=10602621](https://news.ycombinator.com/item?id=10602621)

I was able to replicate this on my own server too, but haven't immediate
solution (all the obvious things like OCSP stapling were already configured,
following common sense and various "best practices" guides) and I hadn't
enough spare time to properly investigate why TLS takes longer.

If someone had encountered this or knows the possible culprits, would be glad
to hear suggestions.

~~~
geofft
I don't currently see a 500 ms difference, so maybe they figured something
out. From my shell, I see about 35 ms to
[http://www.stavros.io/404](http://www.stavros.io/404) and about 85 ms to
[https://www.stavros.io/404](https://www.stavros.io/404) (the HTTPS site
serves actual content and the HTTP a redirect, which confounds the numbers).

The HTTPS server is currently offering me a 4096-bit-RSA certificate, signed
by the 2048-bit-RSA StartCom class 1 intermediate CA. There's no security
benefit in a 4096-bit cert signed by a 2048-bit one, since any attacker
capable of breaking 2048-bit RSA but not 4096-bit is just going to attack the
CA cert and sign their own forged cert (and any attacker _sorta_ capable of
breaking 2048-bit RSA will dedicate their brute force effort to CA certs). And
to my knowledge, all current CA intermediate certs are 2048-bit. Meanwhile,
because of math, 4096-bit certs take a lot longer to handshake: see e.g.
[https://certsimple.com/blog/measuring-ssl-rsa-
keys](https://certsimple.com/blog/measuring-ssl-rsa-keys)

CertSimple's data indicates a 25 ms difference between 2048-bit and 4096-bit
keys on their server, so I'd expect that the 4096-bit key is responsible for
at least most of the performance difference here. A few years ago I screwed
this up on a production shared web host, and I believe we saw a greater than
50 ms difference. (While we're at it, that cert is SHA-1, so it's possible
they can get a reissue for free.)

Were you able to replicate the 500 ms (!) performance difference on your own
server? Are you using a 2048-bit cert and reasonable cipher suites?

~~~
drdaeman
Currently I see ~200ms difference (repeated those tests a good number of
times, of course, those are results closest to average):

    
    
        $ time curl -4 -s -o /dev/null https://drdaeman.pp.ru
        curl -4 -s -o /dev/null https://drdaeman.pp.ru  0.00s user 0.00s system 2% cpu 0.300 total
    
         $ time curl -4 -s -o /dev/null http://drdaeman.pp.ru
        curl -4 -s -o /dev/null http://drdaeman.pp.ru  0.00s user 0.00s system 7% cpu 0.107 total
    

The host isn't doing anything, although the server is old weak Atom machine so
it could take some time to do RSA. I followed some guides (say, used Mozilla-
recommended cipher list) to get "A+" rating with SSLLabs. Currently it's just
"A", I guess because of SHA1 deprecation on Startcom intermediate certs.
[https://www.ssllabs.com/ssltest/analyze.html?d=drdaeman.pp.r...](https://www.ssllabs.com/ssltest/analyze.html?d=drdaeman.pp.ru&s=188.64.129.5)

I'm also using 4Kbit RSA keys, maybe that's the cause, especially given that
the server is a tiny Atom HTPC sitting in the kitchen (100ms is because I'm
accessing it from the other country). Will try to find some time on weekend
and test with 2Kbit ones to see if this is indeed the cause.

\--------------

Added: seems that this worsens with latency, because I see extra 200ms. Maybe
the cause is extra network round-trips, not crypto overhead. Or maybe there's
something with my curl...

    
    
        $ time curl -4 -s -o /dev/null http://stavros.io/404
        curl -4 -s -o /dev/null http://stavros.io/404  0.00s user 0.00s system 4% cpu 0.180 total
    
        $ time curl -4 -s -o /dev/null https://stavros.io/404
        curl -4 -s -o /dev/null https://stavros.io/404  0.01s user 0.00s system 2% cpu 0.370 total
    

Unfortunately, don't have time to meditate on Wireshark output right now. :(

~~~
geofft
> I'm also using 4Kbit RSA keys, maybe that's the cause, especially given that
> the server is a tiny Atom HTPC sitting in the kitchen

Yeah, the combination of those two things is very likely to not do you any
favors.

It is worth clarifying that Google et al.'s claim that SSL is essentially no
overhead is conditioned on the assumption that you're using reasonably modern
and full-featured processors, especially with AES-GCM in hardware. (Which is
pretty common on laptop processors these days even without trying hard to find
it, but probably won't be on an Atom HTPC.) I think that's reasonable, since
if you're seriously worried about performance and latency, you're probably
starting off with good hardware, and your worry is that investment will go to
waste if you turn on SSL. At least for running a web server for fun on an old
personal machine, the added latency is real and is unfortunate but I'd guess
also not such a big deal. But maybe that's a bad assumption?

------
josteink
Yeah. Still not paying for a cert on my person home-pages just so I can have
my own page come up first when people google my (worldwide unique) name.

That page contains static HTML and does not need SSL, and it's not "insecure"
just because you may be on a network which MITMs traffic. That makes _your
network_ insecure, not my page.

So yeah. Not interesting. Not worth it.

~~~
gilrain
Just set mine up for free, today. Letsencrypt.org works great. I recommend the
simp_le client.

~~~
dawnerd
Yeah, there's really no excuse anymore really. They've made it insanely easy
to generate certs.

------
sqldba
If they could just wait until cPanel has LetsEncrypt support that would be
great...

------
civilian
It's funny that vice themselves doesn't automatically forward to https.

------
tobltobs
And I always thought TLS is the virtual equivalent to those TSA locks.

~~~
chipperyman573
What gave you this impression?

~~~
tobltobs
The uncontrollable number of masterkeys.

------
dh997
HN could do its part: for example, start marking all [http://](http://) links
red. For our content sites, we can also announce to users this change and roll
something out.

------
dh997
Basically efficient, low-latency caching for html and css content is over
unless there's SRI for them. It makes sense to have a mini webpage delivered
securely that lists hashes for all static assets, and then serve some static
assets insecurely to take advantage of CDNs as long as they don't disclose
individual app actions (assets everyone sees on many pages). The downside is
the balancing of risk for activity leakage based on insecure assets. Of
course, some dynamic content and sensitive state needs to remain secure. The
issue is that securing everything depends on whether you're willing to trust
your CDNs and caches with your certs and private keys (granted, you already
trust them to display the correct content.). That sort of technical risk
management needs to be considered carefully if insecure assets can
dramatically speed up UX (because TLS sessions take some or a lot more work...
since how would the browser and backends do session caching or pipelining
across infrastructures and providers that likely have multiple IPs? One
connection per provider, each keeping their own cache for their HA boxes?)

Maybe there needs to be an insecure HEAD or CACHE open standard to check
content freshness of a secure page via crypto hash (say canonical uri, etag
and last modified) to avoid building up a full TLS session to see nothing's
changed?

