Live data from Hacker News

HTTPS by default

security.googleblog.com

221–230 of 268 posts

Re: HTTPS by default

#221

Earlier quoted context omitted.

Sounds like a great argument for keeping js disabled in my browser. Because "httpS://" does nothing whatever to sanitize the js that it delivers. And one perfectly legit site may pull in js from two dozen or more different servers. Zero of which are magically guaranteed to only deliver benevolent code. Vs. `traceroute` suggests that would-be on-path attackers are up against a vastly smaller attack surface.

> Sounds like a great argument for keeping js disabled in my browser. Because "httpS://" does nothing whatever to sanitize the js that it delivers. And one perfectly legit site may pull in js from two dozen or more different servers. Zero of which are magically guaranteed to only deliver benevolent code. See: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Yes, great. When used. And maintained. All the way down the foo.js => bar.js => baz.js => etc.js chain.

Might you know which js blockers support "only with 'integrity='" conditionals?

Re: HTTPS by default

#222

Earlier quoted context omitted.

Honestly I don't even think technical users would get the 'point' most of the time. Whenever I visit a HTTP-only site, I assume the administrator is either old and does not understand how to set up SSL, or it's an unmaintained/forgotten web server that hasn't been touched in about a decade.

> When ... I assume the ... If it's (1) obviously recent content*, and (2) something that needs little security - a city council member's blog, or recipes - then how much do you care that it's HTTP-only? *Or just date-insensitive

That's precisely the point of HTTPS, your harmless recipe site can start spreading malware without your knowledge if you make it HTTP, as the content can be changed by anyone it passes through.

Re: HTTPS by default

#223
post #174

This is to be honest a little unfortunate. While Https is very important, do we really need to verify that Blog X that I may read once a year is really who they say they are? For many sites it doesn't make a lot of sense but we are here due to human nature

I stopped reading all print media, obeying any physical traffic signs, or having conversations on the phone etc. years ago.

I'm not going to drive 35mph without a trusted certificate authority verifying that sign wasn't tampered with by a MITM. My grandma tried to tell me she loved me over an unencrypted and insecure phone line the other day - nice try, hackers!

Re: HTTPS by default

#224

The only challenge to https, as compared to http, is certificates. If not for certificates I could roll out a server with https absolutely anywhere in seconds including localhost and internal intranets. On another note I would much prefer to skip https, as the default, and go straight to WSS (TLS WebSockets). WebSockets are superior to HTTP in absolutely every regard except that HTTP is session-less.

It's not even certificates that's the problem, but trust. And here Google is making exceptions to allow unencrypted connections to private addresses, because trust is hard. If encryption was not tied to trust, then we would have 0 unencrypted connections by now and we would be that much better off. Making an exception to allow plain HTTP connections instead of making an exception to allow self-signed certificates, se…

Yeah, that is an excellent point. I really wish there were a unique icon for self-signed certificates opposed to other untrusted certificates. Self-signed certificates are not deceptive or malicious but they are not trusted. In a localhost environment self-signed certificates from the host machine are perfectly fine. Even better would be if browsers did not require certificates at all to make use of HTTPS from localhost, 127.0.0.1, or ::1

Re: HTTPS by default

#225
If I set a DNS entry that points to a private ip (e.g, A internal.domain.com 192.168.0.5), will the allow private site setting succeed or fail for http://internal.domain.com?

Either way I agreee with this update. It's better to put the burden of knowledge on those hosting things locally and tinkering with DNS than those that have no idea that a domain does not infer ownership of said domain.

Re: HTTPS by default

#226

I have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing. I think it's important to emphasise that although Tim'…

I run my blog in unencrypted HTTP/1.1 just to make a point that we do not have to depend on third parties to publish content online. And I noticed that Whatsapp is even worse than Chrome, it opens HTTPS even if I share HTTP links.

Would you tolerate using DANE?

Re: HTTPS by default

#227

I have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing. I think it's important to emphasise that although Tim'…

> The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing.

Interesting, that hasn't been my experience. There's a certain group of stubborn techies who have active sites lacking HTTPS. One example is Dave Winer's blog:

http://scripting.com/

He's doing some really interesting things over at https://feedland.com, so I'm glad I clicked through the TLS warning on his blog.

Re: HTTPS by default

#228

I have had HTTPS-by-default for years and I can say that we're past the point where there's noticeable year-to-year change for which sites aren't HTTPS. It's almost always old stuff that pre-dates Let's Encrypt (and presumably just nobody ever added HTTPS). The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing. I think it's important to emphasise that although Tim'…

> The news site which stopped updating in 2007, the blog somebody last posted to in 2011, that sort of thing. Interesting, that hasn't been my experience. There's a certain group of stubborn techies who have active sites lacking HTTPS. One example is Dave Winer's blog: http://scripting.com/ He's doing some really interesting things over at https://feedland.com , so I'm glad I clicked through the TLS warning on his bl…

There is always someone who has a different experience, but I think Google numbers 95-99% is pretty much correct and websites with decent amount of traffic all have HTTPS.

Re: HTTPS by default

#229
post #91

Mmmm, great that and mandatory key rotation every 90 days, plus needing to get a cert from an approved CA, means just that more busy work to have an independent web presence. I don't like people externalizing their security policy preferences. Yes this might be more secure for a class of use-cases, but I as a user should be allowed to decide my threat model. It's not like these initiatives really solve the risks pose…

This is all automatable and is well documented for almost every setup. If you're on a cloud provider/CDN it's even easier as they'll handle all this for you at pretty much no cost.

You can also still use your own threat model. You can use self-signed certs, import your own CA, etc. The issue is that browsers need to service the mass market, including the figurative grandma who won't otherwise understand fake bank certificates.

As for email, yes...that is a complete shitshow and I'm still surprised it works as well as it does.

Re: HTTPS by default

#230

Earlier quoted context omitted.

> they have their own built-in encryption What does this mean? Is that encryption not reliant on any third parties, or is it just relying on different third parties?

The onion URL is itself a public key - https://protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7... for example. Proton Mail burned CPU time until they found a public key that started the way they wanted it to. So that is the public key for an HTTPS equivalent as part of the tor protocol. You can ALSO get an HTTPS certificate for an onion URL; a few providers offer it. But it’s not necessary for security - it does…

If everyone who wants a human readable domain did this, it would environmentally irresponsible. Then 'typo' domains would be trivial. protonmailrmez31otcciphtkl or protonmailrmez3lotcciphtkl.

Its a shame these did put in a better built-in human readable url system. Maybe a free form text field 15-20 characters long appended to the public key and somehow be made part of that key. Maybe the key contains a checksum of those letters to verify the text field. So something like protonmail.rmez3lotcciphtkl+checksum.

But this being said, I think being a sort of independent 'not needing of third parties' ethic just isnt realistic. Its the libertarian housecat meme writ large. Once you're communicating with others and being part of a shared communal system, you lose that independence. Keeping a personal diary is independent. Anything past that is naturally communal and would involve some level of sharing, cooperation, and dependency on others.

I think this sort of anti-communal attitude is rooted in a lot of regressive stuff and myths of the 'man is an island' and 'great man' nonsense. Then leads to weird stuff like bizarre domain names and services no one likes to use. Outside of very limited use cases, tor just can't compete.

Post reply on HN