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

171–180 of 369 posts

Re: Google Will Soon Shame All Websites That Are Unencrypted

#171

Post by dkonofalski »

BinaryIdiot wrote: post #161
callmeed wrote: post #156

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…

Yeah I'm all for SSL shaming but my personal site with SquareSpace is about to look like shit for me since I'm a web developer. I mean as a web developer it's not going to look good if your portfolio is shown with a security warning. I wonder if SquareSpace is going to finally fix their shit or if I'm going to have to move elsewhere which is going to be a pain (I went with SquareSpace because I didn't want to be asse…

No offense intended with this, but, as a web developer, what the heck are you doing creating your site on SquareSpace? Shouldn't you...I dunno...develop your own web site?

Re: Google Will Soon Shame All Websites That Are Unencrypted

#172

Post by 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?

Re: Google Will Soon Shame All Websites That Are Unencrypted

#173

Post by cellularmitosis »

nothrabannosir wrote: post #50
rwmj wrote: post #31

Earlier quoted context omitted.

SSH gets this right -- create a host key when the server is installed, and have the client check the key and only warn/error when it changes. Sure, this isn't super-secure for first time visitors to their banking website or whatever, but those websites can continue to use the current system.

SSH doesn't get this right. It's no better than a (auto-pinned) self-signed cert, in our world. I challenge everyone to find in their extended group of friends and colleagues, and their friends and colleagues, a single person who consistently checks the fingerprint* on every first SSH connection. Id personally have a hard time finding someone who even knows it matters. And if you don't? Mitm can get your password, or…

Still, there's a difference between being less than 100% secure and being a totally useless feature.

Being able to make the statement "Either you've been consistently MitM'ed by the same entity for the past three years, or the your little cloud-based debian box is actually secure" is a lot more useful than not tracking SSH fingerprints at all. I certainly wish my browser would track my self-signed certs in this way.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#174

Post by icebraining »

callmeed wrote: post #156

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…

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.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#175

Post by mediumdeviation »

callmeed wrote: post #156

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…

I've managed to get Let's Encrypt working on a shared hosting environment using letsencrypt-nosudo in less than half an hour from the time I started cloning the repo to finally pasting the cert into cPanel. And every step in that process except the final one of installing the cert using cPanel can be automated.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#176

Post by NetStrikeForce »

Someone1234 wrote: post #4

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…

Not only that, but encrypted content from an unverified source is fucking sin for every browser out there, while unencrypted content from an unverified source is fine.

Go figure.

Re: Google Will Soon Shame All Websites That Are Unencrypted

#177

Post by Throwaway23412 »

5ilv3r wrote: post #166

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.

Are there hardware requirements for encryption? And, if there are, who are these people building web sites on hardware older than 2005?

Re: Google Will Soon Shame All Websites That Are Unencrypted

#179

Post by zackboe »

callmeed wrote: post #156

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…

Plesk built a Let's Encrypt extension: https://devblog.plesk.com/2015/12/lets-encrypt-plesk/

Re: Google Will Soon Shame All Websites That Are Unencrypted

#180

Post by schoen »

Syrup-tan wrote: post #170
schoen wrote: post #152

Earlier quoted context omitted.

Hi, I think the IIS support effort that's furthest along is described at https://community.letsencrypt.org/t/how-letsencrypt-work-for... ; maybe that will be useful for you if you want to try Let's Encrypt on your IIS system. We've had hundreds of people remark that they found Let's Encrypt faster and easier to use than other CA offerings (though most of those people were using Apache on Debian-based systems), so I t…

You have a ";" at the end of your URL which breaks it. https://community.letsencrypt.org/t/how-letsencrypt-work-for...

Thanks, edited.
Post reply on HN