Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Will Soon Shame All Websites That Are Unencrypted

motherboard.vice.com

Post reply on HN
Print view View original

131–140 of 369 posts

Re: Google Will Soon Shame All Websites That Are Unencrypted

#131

Post by geofft »

plasticxme wrote: post #115
mholt wrote: post #96

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 - 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…

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.

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

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.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#132

Post by tdkl »

SanderMak wrote: post #16

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

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

Re: Google Will Soon Shame All Websites That Are Unencrypted

#133

Post by geofft »

betenoire wrote: post #114
EGreg wrote: post #108

Earlier quoted context omitted.

Here's a good excuse for not using https for everything: it breaks caching of files by proxies!

Right. So what's the solution? I run my wife's retail website. Am I supposed to just stop worrying about caching static assets like product images, scripts, etc.? Do I just throw my hands in the air and assume it evens out because I switched to HTTPS? Serious question, what are my options?

Do you run the cache / contract with someone to run the cache, or are you worried about third parties who run caching servers out of your control (like mobile ISPs, corporate networks, etc.)? If the latter, I'm surprised/curious what the use case is.

If the former, you can stick those on HTTPS too just fine. CloudFlare will be an entire SSL-enabled CDN for you for free. Amazon Cloudfront will serve SSL for you for free (though you still have to pay for Cloudfront itself, and get a cert on your own, though you can do that for free).

Re: Google Will Soon Shame All Websites That Are Unencrypted

#135

Post by betenoire »

jacobr1 wrote: post #130
betenoire wrote: post #114

Earlier quoted context omitted.

Right. So what's the solution? I run my wife's retail website. Am I supposed to just stop worrying about caching static assets like product images, scripts, etc.? Do I just throw my hands in the air and assume it evens out because I switched to HTTPS? Serious question, what are my options?

* Ensure your server is setting ETags correctly so the clients can determine which assets they need to re-request. * Make use of edge CDNs with https termination

Turns out my CDN supports HTTPS (using cloudinary), so that's good. Thanks for the ETag reminder, I'm not doing that yet.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#136

Post by tbirdz »

geofft wrote: post #47
bjblazkowicz wrote: post #35

So what about the overhead of https?

For the last few years, effectively zero. https://istlsfastyet.com/ https://www.maxcdn.com/blog/ssl-performance-myth/ https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h... 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 .

On Intel x86_64 platforms with AES-NI hardware accelerated AES, sure. On other platforms, not so much.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#138

Post by geofft »

snowwrestler wrote: post #109
toyg wrote: post #106

Earlier quoted context omitted.

... 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?

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.

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/10/sustaining...

"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

Re: Google Will Soon Shame All Websites That Are Unencrypted

#139

Post by ergothus »

notatoad wrote: post #107
ergothus wrote: post #66

Earlier quoted context omitted.

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

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.

TIL, though many people with a domain are going to want their accounts through it.

That said "delayed schedule" above means 1+ years.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#140

Post by drdaeman »

geofft wrote: post #110
drdaeman wrote: post #93

Earlier quoted context omitted.

I thought the same, but reality isn't that nice. Got this response: 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 enco…

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 and about 85 ms to 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…

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

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. :(
Post reply on HN