Live data from Hacker News

HTTPS Everywhere will sunset in January 2023

eff.org

111–120 of 148 posts

Re: HTTPS Everywhere will sunset in January 2023

#111

Earlier quoted context omitted.

Then nut up and donate the millions yourself.

That doesn't follow. Do you really want to argue that the only way someone is allowed to disagree with millionaires is by being one themselves?

What's the EFF to do?

1. Achieve its mission with no money, or 2. Find money from sources deemed acceptable, or 3. Take money from sources deemed unacceptable

I'm OK with option 3, so long as its transparent, because I agree with the agenda the EFF are pushing. If they start pushing an agenda I disagree with, I'll stop supporting them, whether or not they receive money from Google et al.

Re: HTTPS Everywhere will sunset in January 2023

#112

Earlier quoted context omitted.

HTTP is not ok. Anyone can ready / modify what is being sent. This privacy intrusion will definitely happen, whereas the risk of being banned by "some external corporation" is low. And, you always have the option of self-signing your own certificate, which is at least as secure as using HTTP, and much more secure if you can verify the certificate via a side channel.

> HTTP is not ok actually, it is. HTTP is perfectly fine. [1] > Anyone can ready / modify what is being sent Anyone can break a window and enter my house. But I haven't aired a private army to patroll the windows. NSA can break HTTPS, TGF exists and China Trusted SSL Certificates are a thing. False sense of security is often more dangerous than a real sense of insecurity. Edit: [1] how many of you don't terminate SSL…

HTTP has been used as an attack vector in the past and there’s no reason to think it won’t be again in the future. HTTPS on your site protects the rest of us from it being used by things like China’s Great Cannon.

Re: HTTPS Everywhere will sunset in January 2023

#113

Earlier quoted context omitted.

Ok, so the NSA could have replaced the phone numbers we sent each other, which means that we can't be sure that the NSA isn't intercepting our file transfer later, which is the exact same issue we would face had we using HTTPS to transfer the file, except we did a lot more work (e.g. exchanged numbers, texted file hashes, compared check sums, etc.). btw, citation needed that the NSA is able to decrypt https traffic.

> Ok, so the NSA could have replaced the phone numbers we sent each other What if we're living in a black hole and our universe is a white hole? > except we did a lot more work Or we trust the sender to not be malevolent and/or compromised, like Debian did for more than 20 years. I don't understand why people live like they are surrounded by enemies in enemy territory, given it's not usually the case. HTTP is perfect…

> Or we trust the sender to not be malevolent and/or compromised, like Debian did for more than 20 years.

I mentioned this above, but when was Debian ever doing this? I don't think I've ever used a package manager that wasn't at least making some attempt to secure against MITM attacks and compromised CDNs.

> Or we trust the sender to not be malevolent and/or compromised

That's not what HTTPS protects against, HTTPS is designed to protect against MITM attacks. It doesn't inherently have anything to do with verifying identity, and we've actively moved away from identity verification in the SSL world, because the companies trying to do identity verification to determine which certificates were "verified" added very little security to the process and were mostly a waste of money.

LetsEncrypt pretty much only cares whether or not you control the domain you say you control. It doesn't verify your identity past that point, because that's not its job. It solves a specific problem.

> Also: 99% of corporate networks install self signed certs and override the certification authority, so traffic is inspectable.

I don't personally like when companies do this, but it's not breaking HTTPS. If the user or device owner imports a certificate authority, then the browser should trust it. Isn't that the whole criticism people have with HTTPS, that they don't like gatekeepers? They should be happy that device owners can swap out certificate authorities.

> HTTPS is not a panacea.

Carrots and spinach are not a health panacea, but that doesn't mean I'm obligated to eat dirt instead.

There are definitely alternative schemes that could be used in the browser other than HTTPS. It's OK if you don't like HTTPS in specific. But that doesn't mean HTTP is secure.

Re: HTTPS Everywhere will sunset in January 2023

#114

Is https enough or do we also need hsts? And how does QUIC fit into all of this?

Pretty much all browsers will try HTTPS first if you type a URL without a protocol. HSTS only practically helps in the case where you have URLs that have the wrong protocol.

QUIC and H2 are both always encrypted. But since quic is purely supplemental at this point, it really doesn't factor into anything relevant here.

Re: HTTPS Everywhere will sunset in January 2023

#115
post #88
post #4

This is the kind of sunset you love to see. Retirement because they succeeded and therefore became redundant, rather than due to failure. If there's one organization I love to see succeed, it's the EFF.

Not entirely. They don't provide an alternative to "HTTPS Everywhere User Rules" as well as adding exceptions to HTTPS only sites (under "HTTPS Everywhere Sites Disabled"), which can be found in HTTPS Everywhere options. In Chromium I can only turn HTTPS on all sites, without exception. It also doesn't allow me to have mixed content (on certain sites)

Well Firefox has also exceptions.

Re: HTTPS Everywhere will sunset in January 2023

#116
post #100
post #87

Earlier quoted context omitted.

I am arguing that the best you can do is not even have HTTP enabled. A permanent redirect is the second best ;) And yeah, most practical for commercial entities (which is why I highlighted what I do for my personal sites).

The best you can do is set HSTS and redirect from http to https. You not serving http won't prevent a MITM from serving http to the victim.

There's a corner case where users who have never visited your domain (either ever or just on that browser) do so for the first time over a malicious connection. In this case, Mal sends them a page that looks reasonable, they create an account or login or whatever, Mal gets the password and probably proxies the requests to the origin domain (properly over https so even if the site operator redirects all pages to https, this still works) so that the user gets the email confirmation or whatever.

A tiny bit better is to submit your domain to https://hstspreload.org/ so that (major) browsers force https on the first connection. You should still set the HSTS header of course, it's a requirement for inclusion in the preload list and it should also catch people who have a browser from before your inclusion in the list or browsers that don't support the preload list at all.

Re: HTTPS Everywhere will sunset in January 2023

#117
post #78

Earlier quoted context omitted.

That’s how I used to feel until I found out they accepted millions in donations from companies like Google and Facebook/their executives/their executives’ charities. I’m just some guy on the Internet but IMHO their being OK with massive conflicts of interest means I no longer trust them.

Would you turn down millions of dollars in no-strings-attached donations if you were running a charity? What was the negative result of those donations that you can point to? I'm not a fan of Google or Facebook, but I also don't outright boycott everything that they've ever touched. They donate money and developer time to tons of projects that I use regularly (including Linux), and it would be hypocritical of me to l…

It’s not bad from Google or Facebook’s perspective, it’s bad for the EFF. Accepting money from the organizations you’re supposed to be monitoring is a conflict of interest. You shouldn’t have to question whether that money affected their behavior towards those organizations and now you do. They should not have accepted it, arguably they didn’t need to.

Re: HTTPS Everywhere will sunset in January 2023

#118

Is https enough or do we also need hsts? And how does QUIC fit into all of this?

Pretty much all browsers will try HTTPS first if you type a URL without a protocol. HSTS only practically helps in the case where you have URLs that have the wrong protocol. QUIC and H2 are both always encrypted. But since quic is purely supplemental at this point, it really doesn't factor into anything relevant here.

The reason to use https is because we assume there could be a malicious party between you and the site you're visiting.

If we assume that, we should further assume that they will inspect SNI in your https request, see that you're visiting some domain they are interested in, and just block that request (or creatively fail to make a good https connection, to arouse less suspicion), causing your browser to helpfully fall back to plain http. But this is exactly the behavior we don't want.

HSTS (or firefox's force https setting, probably similar settings exist for other browsers, or HTTPS Everywhere's strict setting) makes your browser insist on using https for connections to that domain, and showing an error page if it's not possible.

Re: HTTPS Everywhere will sunset in January 2023

#119
post #62

Earlier quoted context omitted.

The article talks about how to get this HTTPS by default functionality in all major browsers. I don't see how your complaint about not being redirected to HTTPS is relevant with those settings enabled.

There's still plenty of useful websites that are HTTP-only or that have HTTPS misconfigured. The HTTPS-only mode will break them, whereas HTTPS Everywhere just works.

Exactly this. In Firefox, the suggested replacement is to use the force https setting, but that is for the whole browser instance instead of the domain of the current tab. If I disable force https to make some site work, I have to remember to turn it back on when I'm done, and if I'm going back and forth between sites on different tabs/windows where some support https and some don't, it's a huge pain.

I don't even know how disabling it affects already-loaded pages in other tabs. If each page/tab caches the setting on page load and still respects it when it gets changed, maybe that's fine... but if js-driven background requests on all my other tabs suddenly don't force https when I disable the setting to visit paulgraham.com, then that's not a good replacement for https everywhere.

Re: HTTPS Everywhere will sunset in January 2023

#120

Earlier quoted context omitted.

HTTP is not ok. Anyone can ready / modify what is being sent. This privacy intrusion will definitely happen, whereas the risk of being banned by "some external corporation" is low. And, you always have the option of self-signing your own certificate, which is at least as secure as using HTTP, and much more secure if you can verify the certificate via a side channel.

> HTTP is not ok actually, it is. HTTP is perfectly fine. [1] > Anyone can ready / modify what is being sent Anyone can break a window and enter my house. But I haven't aired a private army to patroll the windows. NSA can break HTTPS, TGF exists and China Trusted SSL Certificates are a thing. False sense of security is often more dangerous than a real sense of insecurity. Edit: [1] how many of you don't terminate SSL…

> how many of you don't terminate SSL at load balancer?

Oof, this just reminds me of the whole PRISM thing [0] where NSA was tapping inter-DC fiber links and Google wasn't encrypting (some of) the traffic between DCs

[0] https://slate.com/technology/2013/10/nsa-smiley-face-muscula...

Post reply on HN