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

HTTPS Everywhere will sunset in January 2023

eff.org

Post reply on HN
Print view View original

121–130 of 148 posts

Re: HTTPS Everywhere will sunset in January 2023

#121

Post by peoplefromibiza »

danShumway wrote: post #113
peoplefromibiza wrote: post #106

Earlier quoted context omitted.

> 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 i…

> I mentioned this above, but when was Debian ever doing this? I

They are still doing it!

On my system (this one's not Debian, but KDE Neon)

    $ cat /etc/apt/sources.list
    deb http://archive.ubuntu.com/ubuntu/ focal main restricted universe multiverse
    deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
> That's not what HTTPS protects against, HTTPS is designed to protect against MITM attacks

That need a MITM

Which is a specific type of attack.

If you are running a network where that's not possible, you're fine.

> LetsEncrypt pretty much only cares whether or not you control the domain you say you control

LetsEncrypt is pretty much an advanced tool, for advanced users

> I don't personally like when companies do this, but it's not breaking HTTPS.

It's breaking confidentiality.

Which is one of the features of HTTPS

In a corporate network MITM attacks are not that easy to pull off.

So basically HTTPS main feature is encryption of content in that context.

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

first of all, carrots and spinach are a panacea.

Secondly, HTTP is not dirt.

Like SMTP is not dirt and IRC is not dirt and FTP is not dirt and TFTP is not dirt

> But that doesn't mean HTTP is secure. an ex nobody said HTTP is secure, but it's not inherently insecure, like every plain text protocol it's plain text.

it's the network that is insecure, MITM is not an exclusive of HTTP.

If the network is secure, HTTP is secure.

In my kubernetes clusters, TLS is terminated at load balancer and PODS talk to each other using plain simple HTTP.

Wasting energy on useless cryptography "just because" is not very smart IMO.

Re: HTTPS Everywhere will sunset in January 2023

#122

Post by AtNightWeCode »

philsnow wrote: post #118
bastawhiz wrote: post #114

Earlier quoted context omitted.

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 fal…

What I don't get is what is the purpose of HSTS if HTTPS is enforced in the first place. Several (most?) security checkers will warn if HSTS is not enabled for a site. From the tests I have done it seems impossible to get QUIC and HSTS to even work on the same site.

Re: HTTPS Everywhere will sunset in January 2023

#123

Post by tialaramex »

robjan wrote: post #40
silviot wrote: post #6

Earlier quoted context omitted.

Thanks! I'll stop using captive.apple.com now that I know about this!

You can also use example.com. I find that easier to remember.

The example names are just examples, it so happens that today they have a web site and it isn't HSTS. Tomorrow maybe they have HSTS. The week after maybe they get rid of the web site. The names are merely examples, and so it's probably a bad idea to use them for any other purpose.

Re: HTTPS Everywhere will sunset in January 2023

#124

Post by at_a_remove »

GeorgeTirebiter wrote: post #107
at_a_remove wrote: post #76

Earlier quoted context omitted.

We've had more security alerts from OpenSSL and other cert-related software than the man-in-the-middle attacks.

To be fair: if there were successful MIM attacks by the black hats -- how would we know?

To be fair ... that's true of most attacks.

Re: HTTPS Everywhere will sunset in January 2023

#125

Post by tialaramex »

philsnow wrote: post #116
C4K3 wrote: post #100

Earlier quoted context omitted.

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…

You could also choose names whose parent domain is already HSTS pre-loaded. The .dev TLD is pre-loaded for example.

Re: HTTPS Everywhere will sunset in January 2023

#126

Post by tialaramex »

AtNightWeCode wrote: post #122
philsnow wrote: post #118

Earlier quoted context omitted.

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 fal…

What I don't get is what is the purpose of HSTS if HTTPS is enforced in the first place. Several (most?) security checkers will warn if HSTS is not enabled for a site. From the tests I have done it seems impossible to get QUIC and HSTS to even work on the same site.

> From the tests I have done it seems impossible to get QUIC and HSTS to even work on the same site.

I don't understand, maybe you need to explain "the tests I have done" here ?

Re: HTTPS Everywhere will sunset in January 2023

#127

Post by AtNightWeCode »

tialaramex wrote: post #126
AtNightWeCode wrote: post #122

Earlier quoted context omitted.

What I don't get is what is the purpose of HSTS if HTTPS is enforced in the first place. Several (most?) security checkers will warn if HSTS is not enabled for a site. From the tests I have done it seems impossible to get QUIC and HSTS to even work on the same site.

> From the tests I have done it seems impossible to get QUIC and HSTS to even work on the same site. I don't understand, maybe you need to explain "the tests I have done" here ?

Enabling HTTP3 and HSTS on major cloud platforms like Cloudflare (Enterprise) and so on only seems to enable QUIC/HTTP3 and the HSTS headers are no where to be seen. Is HSTS even a thing?

Re: HTTPS Everywhere will sunset in January 2023

#128

Post by danShumway »

peoplefromibiza wrote: post #121
danShumway wrote: post #113

Earlier quoted context omitted.

> 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 i…

> I mentioned this above, but when was Debian ever doing this? I They are still doing it! On my system (this one's not Debian, but KDE Neon) $ cat /etc/apt/sources.list deb http://archive.ubuntu.com/ubuntu/ focal main restricted universe multiverse deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse > That's not what HTTPS protects against, HTTPS is designed to protect against MI…

> They are still doing it!

No, they're not! Debian uses PGP and signature verification to protect against MITM attacks because it is critically important for software downloads to be protected against MITM attacks.

Now, Debian does not use HTTPS in specific to protect against MITM attacks because they have another method baked into the package managers that people are using. It does not follow that HTTP is secure, it's not. It follows that you can use an insecure protocol to deliver software if you bolt the same security features on top of it.

You're looking at someone who has come up with an alternative way to protect users from MITM attacks and thus doesn't use HTTPS, and the conclusion you're drawing is, "I don't need to be concerned about MITM attacks." That's not the right lesson to draw from this.

Is your publicly facing site being accessed by software that automatically checks data integrity using a set of pre-shared keys? No, and no normal person is going to manually do that check when they visit your site, so you need HTTPS.

> If you are running a network where that's not possible,

If your website is accessible to normal browsers on the public Internet, than you're not on a network where that's not possible.

> LetsEncrypt is pretty much an advanced tool, for advanced users

Most free hosts I've looked at recently from Github pages to Netlify have automatic background SSL management for free with zero configuration from the user. If you're running your own server, then you're an advanced user, but even in that situation LetsEncrypt is one of the easiest SSL setups I've ever used.

Any situation where you're using a host who can't manage SSL for you is also probably a situation where you're using a host who can't manage things like DNS or hosting for you, at which point, yeah, I expect you to be able to run a command line tool. If you can install Wordpress on a server, you can use LetsEncrypt. If you can't install Wordpress on a server, you should be using a managed host, and they should install LetsEncrypt.

> It's breaking confidentiality. Which is one of the features of HTTPS

No, HTTPS encrypts data according to the certificate authority. While I don't like networks effectively doing MITM attacks on their own users, it is not the fault of HTTPS that it trusts the authorities that the user's device tells it to trust, any more than it's the fault of Debian if you import an untrustworthy key/repo into package manager.

I was kind of leaving privacy off the table here since you were championing Debian and Debian has substantial privacy issues with software downloads. But if you want to go down that route, than sure, another weakness of HTTP is that it allows tons of network snooping that really shouldn't be possible even for "innocuous" sites that claim they don't have private data on them.

> first of all, carrots and spinach are a panacea.

This is a complete sidenote, but either you don't understand what "panacea" means or you're at risk of Vitamin B12 deficiency. Carrots and spinach are not cure-alls for health, no.

> If the network is secure

It's not. Not if it's accessible from a browser on the public Internet.

> Wasting energy on useless cryptography "just because" is not very smart IMO.

Rejecting basically free cryptography that substantially improves security just because people are determined to be the last holdouts on a move that pretty much every security professional recommends is cutting off one's nose to spite one's face.

People being so concerned about centralization that they start sending messages in plain-text and start arguing with people online that sending messages in plain-text is somehow better for decentralization is at best misguided.

Re: HTTPS Everywhere will sunset in January 2023

#129

Post by nybble41 »

cmeacham98 wrote: post #46
ZWoz wrote: post #38

Earlier quoted context omitted.

Browsers are being pretty weak to understand difference between local networks vs internet. Lot of times I have seen hassle caused by HTTPS, be it printer or server baseboard management controller.

Citation needed. Firefox HTTPS only mode does not upgrade local IP addresses or reserved local "TLDs" like .local. If machines on your "local network" are squatting on a public IP or potentially public domain name how is the browser supposed to know the difference?

> Firefox HTTPS only mode does not upgrade local IP addresses or reserved local "TLDs" like .local. If machines on your "local network" are squatting on a public IP…

It could be one of your public IP addresses—more likely with IPv6, but still possible with IPv4—and not simply "squatting" on someone else's assigned public IP address. The browser may not be aware that these are local.

With that said, the devices should use public domain names and obtain proper certificates for them via the ACME DNS challenge, which avoids the issue altogether.

Re: HTTPS Everywhere will sunset in January 2023

#130

Post by Sohcahtoa82 »

blowski wrote: post #109
otabdeveloper4 wrote: post #70

Earlier quoted context omitted.

It's security theater, it's not meant to solve real problems for real people.

The year 2015 wants its flamewar back.

I was thinking about this classic article [0] that gets linked whenever people talk about HTTPS?

If so, that's a 2017 flamewar.

[0] http://n-gate.com/software/2017/07/12/0/ (NOTE: this site tracks if you come from HN and sets a cookie. You'll probably need to open it in incognito)

Post reply on HN