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

Google and HTTP

this.how

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Google and HTTP

#41

Post by Spivak »

userbinator wrote: post #23
cocktailpeanuts wrote: post #18

There really is no absolute right or wrong to this issue. HTTPS is indeed more secure for users, but it does have some cost, and I think OP has a sensible argument. If you really think HTTPS is the best thing ever and is absolutely better than HTTP in every sense, you're just looking at it superficially. When you start looking into how the entire Internet works and what role each party plays in the ecosystem, and how…

you'll find that HTTPS is THE biggest centralization force of the web This, very much this. Plaintext doesn't require what is essentially authorisation from a central authority in order to communicate.

I think you'll find that even without the CA system that you need the blessing of at least a few people to get your content on the internet.

- Your address needs to be given to you by your ISP or ARIN.

- Major ISPs need route to your address and/or accept your BGP announcements.

- You probably need a name which is bought from a few large DNS management companies or their resellers.

- You're required to have an email address to field abuse complaints which means you most likely will be paying an email provider.

- If you're not running your own hardware you will have to pay a hosting company.

- If your site is large you'll probably need a CDN to handle the traffic of which there are only a few major players.

- Although it's a blacklist you effectively need Google's blessing to not appear on the SafeBrowsing list.

Is the CA system really that much more of a hurdle? No question it's a little scummy at times but it's cheap and relatively low maintenance.

Re: Google and HTTP

#43

Post by tylerhou »

twtw wrote: post #36
libeclipse wrote: post #30

Earlier quoted context omitted.

Blocking HTTP sites is a bit too far, but an insecure warning is perfectly reasonable as, let's be honest, it is not secure.

I edited my post before your response to change it to "flagged," but failed to call out the change initially. Sorry, it's fixed now. For a lot of people, a big scary warning page that says that a page is insecure is essentially a block. Yeah, you can still access it, but a lot fewer people will. > let's be honest, it is not secure. My original post is asking for an explanation of how it isn't secure. I would totally…

I could, in a very tame example, inject a fake donation button which pointed to my own account instead of the author's. In a more extreme and dangerous example, I could inject malicious JavaScript which exploited an unpatched CVE (Meltdown, Spectre) or vulnerabilities in plugins like Flash, if enabled, to gain control of the user's computer.

It's true that these things could also happen over an HTTPS connection, but then the prevention method is "don't go on sketchy websites." It's far more dangerous over HTTP because a user might already trust the site or author themselves.

Re: Google and HTTP

#44

Post by originalsimba »

This is the worst thing I have read in weeks. The author lacks any understanding of the technology and appears to live in a "Google Bubble". tl;dr, don't waste your time.

He's probably trolling.

Re: Google and HTTP

#45

Post by twtw »

tylerhou wrote: post #43
twtw wrote: post #36

Earlier quoted context omitted.

I edited my post before your response to change it to "flagged," but failed to call out the change initially. Sorry, it's fixed now. For a lot of people, a big scary warning page that says that a page is insecure is essentially a block. Yeah, you can still access it, but a lot fewer people will. > let's be honest, it is not secure. My original post is asking for an explanation of how it isn't secure. I would totally…

I could, in a very tame example, inject a fake donation button which pointed to my own account instead of the author's. In a more extreme and dangerous example, I could inject malicious JavaScript which exploited an unpatched CVE (Meltdown, Spectre) or vulnerabilities in plugins like Flash, if enabled, to gain control of the user's computer. It's true that these things could also happen over an HTTPS connection, but…

Thank you for answering.

I still don't see why either of those justify warning the user about the whole page. For the donation button, the browser could easily warn you with a big "insecure!" page when you click on the button. Regarding js exploits, I don't think https fixes that even for non-sketchy websites: I'm thinking of the js malware in ads and the recent cryptocurrency-mining ads on youtube.

Re: Google and HTTP

#46

Post by JeanMarcS »

originalsimba wrote: post #44

This is the worst thing I have read in weeks. The author lacks any understanding of the technology and appears to live in a "Google Bubble". tl;dr, don't waste your time. He's probably trolling.

He’s at the origin of RSS, put the base of podcasting, host one of the first blogging platform...

But yeah, what does he knows...

Re: Google and HTTP

#47

Post by g5095 »

https is only as secure as who's holding your root signing keys (govt agencies). If you want security layer it ontop of https with pub/priv key crypto. https is just the new hoop, jump through it and move on, but lets not pretend https stops anyone important.

Re: Google and HTTP

#48

Post by tyler_larson »

userbinator wrote: post #23
cocktailpeanuts wrote: post #18

There really is no absolute right or wrong to this issue. HTTPS is indeed more secure for users, but it does have some cost, and I think OP has a sensible argument. If you really think HTTPS is the best thing ever and is absolutely better than HTTP in every sense, you're just looking at it superficially. When you start looking into how the entire Internet works and what role each party plays in the ecosystem, and how…

you'll find that HTTPS is THE biggest centralization force of the web This, very much this. Plaintext doesn't require what is essentially authorisation from a central authority in order to communicate.

You misunderstand what CAs are. Or, indeed, what their certificates imply.

CAs don't provide permission, they vouch for an identity.

Saying that CAs give you permission to communicate is like saying notaries give you permission to sign a contract. You can assert your identity without verification as long as the other party in the relationship is fine with the increased risk of fraud.

Similarly, you can use HTTPS without a signed certificate (precisely as you can use HTTP without HTTPS) as long as you and the other party is happy with the risk that Verizon could be "sanitizing" your speech or injecting your real-world identity into all your HTTP requests without your knowledge.

But both the site operator and visitor stand to lose from someone tampering your traffic. And increasingly, it's the users that are getting burned in this relationship.

Re: Google and HTTP

#49

Post by g5095 »

Why is there no proliferation of letsencrypt authorities? If we're all about making https easy and not about central authority, why not have 100+ letsencrypt authorities run by different groups?

The truth is the new decentralised web does not suit the old https signing-AUTHORITY model. it's time for a decentralised system with no authority other than key-holding. The same goes for DNS.

Re: Google and HTTP

#50

Post by feelin_googley »

Why is this flagged?

The author is Dave Winer. Known for many things, among them RSS. HN users seem to like RSS and dislike what happened to Google Reader.

There is nothing unreasonable about supporting both HTTP and HTTPS.

There are decisions that should be left to users. Denying them meaningful options is something that should raise a red flag and spur some commentary.

For example, if users want to use RSS, then we should be wary of any company that effectively tries to dissuade them from using RSS.

Similarly, if users want to use HTTP for some content (and perhaps HTTPS for other content), then we should be wary of any company that effectively tries to dissuade them from ever using HTTP for any content.

Not all content needs to be encrypted. Moreover HTTPS via SSL/TLS is not the only way to distribute encrypted content. We should not pretend there is only one way to do it, let alone coerce people to do it only one way.

As a user, I would be just as satisfied with a page of HTML that is PGP-signed, encrypted and sent over HTTP as I would with HTML sent over a so-called "secure channel" via SSL/TLS, what with the third party reliances the commercial domain name and commercial x509 certificate schemes routinely entail.

Besides the issues of requisite third party involvement in encryption, TLS as implemented so far has some serious weaknesses and shortcomings, and is not the only solution to "secure content". If a company is going to issue warnings to users, then that should be among them. Promoting a false sense of "security" should be avoided.

When a company running the largest search engine on the www penalizes websites for not implmenting some feature, whether it is AMP or HTTPS or something else, this should raise red flags. Expect some commentary.

Post reply on HN