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

51–60 of 63 posts

Re: Google and HTTP

#51

Post by tyler_larson »

anfilt wrote: post #12
ohiovr wrote: post #2

Whats the deal with letsencrypt? If anyone can get a certificate for the domains I own, it can't stop man in the middle attacks. How is this any better than a self signed cert which throws a hissy fit when you visit? Thats a browser issue to me not an inherant technical advantage. Anyone can get a cert from it including criminals. Google sometimes makes the news when they revoke a cert authority because of criminal a…

Lets Encrypt only verifies that the entity requesting the cert basically has control of the domain. I would agree that the biggest issue with TLS is the certificate authorities. All the trust lies in them. If they issue a bad certificate for google, microsoft, usbank ect... It can cause problems. This is part of the reason HTTP key pinning exists. Further, CAs have issued bad certs. It's happened and will happen agai…

> For instance HTTP 2.0 does not require TLS, but none of the browsers support plain text HTTP 2.0. (So the browsers are ignoring the standard)

H2 requires TLS for practical reasons; without it, poorly-written transparent proxies mangle this protocol that they don't understand. Requiring SSL was the solution to this otherwise intractable problem during the initial SPDY work, and became a hard requirement for SPDY. But due to pressure from certain groups during the IETF standardization process (who didn't want the web to "go dark"), this requirement from SPDY was dropped in the official HTTP2 spec.

But dropping the requirement from the spec doesn't solve the problem that put it there in the first place. You still can't reliably use any protocol newer than HTTP/1.1 unencrypted with many ISPs. It's been demonstrated to fail in ways that are difficult to debug and which would otherwise make HTTP2 seem unreliable. So no consumer-facing implementation will let you try.

Re: Google and HTTP

#52

Post by tylerhou »

twtw wrote: post #45
tylerhou wrote: post #43

Earlier quoted context omitted.

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.

> the browser could easily warn you with a big "insecure!" page when you click on the button.

But this implies that whenever you click on any link on a page served via HTTP, the browser should warn you with a big "insecure!" page. I think this is far more obtrusive than a simple "not secure" banner next to the URL.

> I don't think https fixes that even for non-sketchy websites

You're right, if the website served over HTTPS injects random JavaScript/is poorly designed. However, the danger with HTTP is that every single website is vulnerable to this attack, not simply the ones served by malicious or incompetent hosts.

Re: Google and HTTP

#53

Post by c256 »

tylerhou wrote: post #39
userbinator wrote: post #27

Earlier quoted context omitted.

I'm really surprised that this person is a software developer. I'm even more surprised that he still believes this stuff after working for 24 years. I'm really surprised that you think everyone has/should have(?) the same beliefs about such things. He then argues that Google labeling HTTP as not secure is the first step down a path which leads to "blocking the pages outright", which is a prime example of the slippery…

> 20 years ago people thought buying computers on which you can't install software some central authority didn't approve of was preposterous, and yet here we are today with walled gardens and the like. I can install whatever operating system and software I like on almost every single consumer-available computer today. The only prominent "walled garden" is the iPhone, which has < 15% market share. And frankly, I don't…

You should look up Windows 10 S, then look up ‘locked bootloader’, and then maybe check out Google’s moves toward locking out sideloading on Android. I’m not saying the sky is falling, but there are certainly several signs of interest in that direction.

Re: Google and HTTP

#54

Post by Brian_K_White »

libeclipse wrote: post #30
twtw wrote: post #25

Earlier quoted context omitted.

None of these statements convince me that http sites should be default flagged as insecure. Take this site, for instance: http://wilsonminesco.com/6502primer/65tutor_intro.html . It is a great resource, but is not available over https. yeah, it's possible that someone could MITM it to provide me with incorrect info on the 6502, but I don't see the disregard for my privacy. I'm never going to put in any of my own info…

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

Saying a site like that is not secure, is like the famous old advertizing campaign where one of two competeing food products claimed, perfectly truthfully, that there bread or milk or whatever it was, didn't contain any bleach. It's a technically true, yet grossly disingenuous statement. No one's milk had any bleach in it, and that site has no obligation to be secure.

Re: Google and HTTP

#55

Post by [deleted] »

thristian wrote: post #4
ohiovr wrote: post #2

Whats the deal with letsencrypt? If anyone can get a certificate for the domains I own, it can't stop man in the middle attacks. How is this any better than a self signed cert which throws a hissy fit when you visit? Thats a browser issue to me not an inherant technical advantage. Anyone can get a cert from it including criminals. Google sometimes makes the news when they revoke a cert authority because of criminal a…

> If anyone can get a certificate for the domains I own, it can't stop man in the middle attacks. You're right, if that were the case, it would be terrible! Luckily, it's not: to get a certificate for your domain, I need to either control your domain, or control the computer that the domain points at. In either case, you have much bigger problems than certificate issuance.

[deleted]

Re: Google and HTTP

#56

Post by ohiovr »

lasdfas wrote: post #5
ohiovr wrote: post #2

Whats the deal with letsencrypt? If anyone can get a certificate for the domains I own, it can't stop man in the middle attacks. How is this any better than a self signed cert which throws a hissy fit when you visit? Thats a browser issue to me not an inherant technical advantage. Anyone can get a cert from it including criminals. Google sometimes makes the news when they revoke a cert authority because of criminal a…

Let's Encrypt just like every other certificate authority validates that you own the domain before giving you a cert. They do that by sending a request to the domain from their servers (via looking up the nameservers via domain registries) and validating the response matches a unique message generated. You could impersonate google.com on wifi, but you couldn't get a valid cert for google.com because you don't own the…

Thank you! So I'm using a cable modem with a dynamic IP. All someone needs are access to the updater program and credentials to impersonate my domain. So certs are fine and all, as long as those little numbers at the name server never change. I'm a just a hobbyist. Just asking questions, don't mean to offend anyone...

Re: Google and HTTP

#57

Post by foo101 »

twtw wrote: post #45
tylerhou wrote: post #43

Earlier quoted context omitted.

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.

The donation request may not always be in the form of a button. Sometimes it may be a request to make the donation by another means such as by sending bitcoins to a specific address.

Re: Google and HTTP

#58

Post by IshKebab »

feelin_googley wrote: post #50

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…

Probably just because it's full of nonsense.

Re: Google and HTTP

#59

Post by braderhart »

matte_black wrote: post #10
braderhart wrote: post #7

"It may be hard to believe that there was a time when Amazon, Netflix, Facebook, Gmail, Twitter etc didn't exist. Not really.. I dream all the time of a land where decentralized exchanges exist for these services, and that a clunky web browser is not required for accessing information online.

How else would the information be accessed? A separate dedicated app for each of those things? Those exist already.

Through a different markup format and set of tools that follows the unix philosophy.

Re: Google and HTTP

#60

Post by tewha »

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…

My ISP used to inject things into web pages. I don't think they do anymore, but some WiFi access points still do.
Post reply on HN