News for hackers. Stuff that matters.
Re:Google and HTTP by JackSlateur on Tuesday July 04, 2023 @11:49AM (#36588270)
I find this post .. disturbing

HTTPS is not only about "asking user for data" It is also: - preventing third party from spying on you - preventing third party from altering the content presented to the user

Yes, yes, 20 years old websites do not have https Is running a 20 years old software a good idea, on the internet ? Of course not

What is the point of this post ? I read the "why google really wants you to use https" and failed to find any sense in this

Is this meaningless ?

Re:Google and HTTP by forgotmypw17 on Tuesday July 04, 2023 @12:18PM (#36588727)
The privacy protection is a benefit, but it is balanced against accessibility, which is often more important, such as when trying to access important information on an older device.
Re:Google and HTTP by josephcsible on Tuesday July 04, 2023 @12:55PM (#36589309)
How old is the last device you know of that supports insecure HTTP but not HTTPS?
Re:Google and HTTP by sam_lowry_ on Tuesday July 04, 2023 @01:07PM (#36589507)
My Mikrotik routers? My Openwrt routers?

Lots of networking equipment works over HTTP only, still.

I am actually really pissed off that I can not use Chromium password manager to save HTTP credentials for these devices.

Re:Google and HTTP by josephcsible on Tuesday July 04, 2023 @01:09PM (#36589531)
Re:Google and HTTP by sam_lowry_ on Tuesday July 04, 2023 @01:50PM (#36590180)
This is not the default, and frankly should not be.
Re:Google and HTTP by Railander on Saturday July 08, 2023 @05:57PM (#36649189)
> Lots of networking equipment works over HTTP only, still.

MikroTik has supported https for a very very long time, though it comes disabled by default and even if it didn't it wouldn't work because it requires the user creating/importing a cert to use with it.

At least the cert manager is quite intricate and they have a video (assuming the device has a valid WAN IP) on how to set it up with letsencrypt.

Re:Google and HTTP by bscphil on Tuesday July 04, 2023 @02:24PM (#36590693)
Usually supporting HTTPS is combined with requiring relatively recent versions of TLS and cipher suites, for security reasons. I've been in a position where I needed to use a computer from ~2007 or so briefly and found that I couldn't access a huge fraction of websites, despite the fact that the browser "supported" HTTPS.
Re:Google and HTTP by pixl97 on Tuesday July 04, 2023 @05:14PM (#36592569)
2007 on the modern internet... how fast was it compromised when you clicked the wrong link.
Re:Google and HTTP by forgotmypw17 on Tuesday July 04, 2023 @05:38PM (#36592839)
I regularly use old and older devices in my work, and they work fine as long as I don't go to random shady corners of the Web.
Re:Google and HTTP by josephcsible on Tuesday July 04, 2023 @11:52PM (#36595345)
Firefox 27 runs on systems as old as Windows XP SP2, and it supports TLS 1.2 and the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites, which are still considered up-to-date and don't have any known vulnerabilities. If a computer from 2007 couldn't reach modern TLS sites, then it was just behind on updates that were available to it.
Re:Google and HTTP by forgotmypw17 on Wednesday July 05, 2023 @04:01AM (#36597183)
I've commented on this issue before, as I do a lot of testing in the accessibility space, so I'm just going to paste a previous comment:

---

Only a few of the barriers presented by HTTPS:

Clock sync would be a requirement for access.

A recent device would be a requirement for access (not everyone can afford a new one).

Site admin keeping up with certificate registration would be a requirement.

Approval from the centralized certificate authority would be a requirement.

Server's self domain name matching accessed domain name would be a requirement.

These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.

Just a few of the reasons why all my websites still allow HTTP.

HTTP is also way faster on slow connections.

---

https://news.ycombinator.com/item?id=35800566

Re:Google and HTTP by josephcsible on Wednesday July 05, 2023 @10:14AM (#36600776)
> Clock sync would be a requirement for access.

If you have Internet access, NTP trivially gives you this.

> A recent device would be a requirement for access (not everyone can afford a new one).

That's literally the point I addressed in the comment you replied to. Computers that are over 20 years old are still capable of connecting to websites using modern TLS.

> Site admin keeping up with certificate registration would be a requirement.

No, ever since ACME came out, certificate renewal can trivially be fully automated, with zero admin work required when one is about to expire.

> Approval from the centralized certificate authority would be a requirement.

Which is trivially granted as long as you actually own the domain you're trying to get the certificate for.

> Server's self domain name matching accessed domain name would be a requirement.

You can get multiple certificates and have the server use SNI to send every client the right one, or get one certificate with a bunch of domain names.

> These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.

This is like saying that it's dangerous to go outside because there have been real cases of people being killed by meteorites.

Re:Google and HTTP by forgotmypw17 on Wednesday July 05, 2023 @01:07PM (#36603435)
> If you have Internet access, NTP trivially gives you this.

This is not always true, and the user is not always at liberty to change the clock settings on their device.

> That's literally the point I addressed in the comment you replied to. Computers that are over 20 years old are still capable of connecting to websites using modern TLS.

This is just not true. I do a lot of testing, and there are many devices as young as 5 years that cannot access some websites due to TLS incompatibilities. I have a very nice device that's 10 years old which I use daily that experiences this on a regular basis.

> No, ever since ACME came out, certificate renewal can trivially be fully automated, with zero admin work required when one is about to expire.

Automation breaks, and certificates expire. I encounter websites with broken certificates almost daily.

> Which is trivially granted as long as you actually own the domain you're trying to get the certificate for.

It is not trivial at all. It requires a lot of administrative work, and many people around the world do not have access to this process at all.

> This is like saying that it's dangerous to go outside because there have been real cases of people being killed by meteorites.

No, it is like saying there are people out there who want to access information on the device they have access to, and we should enable them to access that information as much as possible.

Re:Google and HTTP by josephcsible on Wednesday July 05, 2023 @04:05PM (#36606288)
> there are many devices as young as 5 years that cannot access some websites due to TLS incompatibilities. I have a very nice device that's 10 years old which I use daily that experiences this on a regular basis.

Can you name the specific models?

> Automation breaks, and certificates expire. I encounter websites with broken certificates almost daily.

How many times have you seen that where the expired certificate came from Let's Encrypt? I'm guessing never, and that when you've seen it, it's always been from legacy ones without any automation in use.

> It is not trivial at all. It requires a lot of administrative work, and many people around the world do not have access to this process at all.

It only takes a few minutes to set up. Who has the required resources to own a domain but not to use Let's Encrypt?

Re:Google and HTTP by JackSlateur on Wednesday July 05, 2023 @04:20PM (#36606511)
Any sane reasons to use a 10 years old tls library ?

I fail to find any;

Re:Google and HTTP by forgotmypw17 on Wednesday July 05, 2023 @05:59PM (#36607764)
The most basic one is that you have a device which you cannot upgrade past that version.
Re:Google and HTTP by bscphil on Wednesday July 05, 2023 @07:14PM (#36608549)
Right - I did end up doing basically this. In this case, though, it was a massive pain to figure out what version of a web browser (a) supported enough cipher suites, and (b) would run on the system in question. And then I had to figure out a way to get the browser on the system to begin with; all the download sites I tried required cipher suites that were too recent!
Re:Google and HTTP by forgotmypw17 on Tuesday July 04, 2023 @05:37PM (#36592814)
Not that old, if you take into account that older HTTPS versions are often not supported by the server. As little as 5 years, in my experience.
Re:Google and HTTP by josephcsible on Tuesday July 04, 2023 @11:53PM (#36595348)
What 5-year-old device only supports older than TLS 1.2? (I assume that's what you meant by "older HTTPS versions".)
Re:Google and HTTP by forgotmypw17 on Wednesday July 05, 2023 @04:05AM (#36597217)
I understand your skepticism, but I'm coming from years of actual testing on many real-world devices that people use everyday and have no agency in upgrading for various reasons.

As I mentioned in other comments, there are many possible areas where HTTPS can present a barrier to a user's access to your resource. Some of these I listed in another comment, which I copy below:

---

Only a few of the barriers presented by HTTPS:

Clock sync would be a requirement for access.

A recent device would be a requirement for access (not everyone can afford a new one).

Site admin keeping up with certificate registration would be a requirement.

Approval from the centralized certificate authority would be a requirement.

Server's self domain name matching accessed domain name would be a requirement.

These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.

Just a few of the reasons why all my websites still allow HTTP.

HTTP is also way faster on slow connections.

---

https://news.ycombinator.com/item?id=35800566

Re:Google and HTTP by josephcsible on Wednesday July 05, 2023 @10:15AM (#36600796)
That doesn't answer what I asked at all, and I already rebutted those points in the other place you posted that: https://news.ycombinator.com/item?id=36597183
Re:Google and HTTP by cutler on Tuesday July 04, 2023 @12:29PM (#36588932)
Sites which don't handle user data do not need HTTPS.
Re:Google and HTTP by naikrovek on Tuesday July 04, 2023 @12:37PM (#36589045)
they do if they don't want a user's ISP to inject ads or modify content in transit.

this does happen

Re:Google and HTTP by bmacho on Tuesday July 04, 2023 @12:54PM (#36589297)
Just make it illegal (I think it already is on most of the world), problem solved.
Re:Google and HTTP by naikrovek on Tuesday July 04, 2023 @02:54PM (#36591094)
you're right. making an activity illegal always stops it.
Re:Google and HTTP by bmacho on Tuesday July 04, 2023 @04:35PM (#36592213)
I don't remember saying that, or anything close to it?

If the law forbids ISPs to show ads or modify the content in any way, then they won't do it.

Re:Google and HTTP by pixl97 on Tuesday July 04, 2023 @05:20PM (#36592630)
No what you stated was "take money out of politics" which is going to be far more difficult then the technical issues we're presented with.

Why that statement, because any law to ban ISPs from doing this will be met with millions in political investment by said ISPs to prevent it. Since the average person doesn't care about this issue it's a losing proposition.

Re:Google and HTTP by davewiner on Tuesday July 04, 2023 @01:38PM (#36589978)
i'm not going to re-do all the sites i did in the 90s, 00s, 10s. never going to happen.
Re:Google and HTTP by naikrovek on Tuesday July 04, 2023 @02:54PM (#36591096)
I'm not asking you to
Re:Google and HTTP by nlewycky on Tuesday July 04, 2023 @03:58PM (#36591816)
Could you elaborate? I thought upgrading to HTTPS wouldn't involve redoing any sites, no changes to the HTML/CSS/JS/server side code, except for the TLS configuration and maybe replacing links from "http:" to "https:" but that's optional. I'd like to hear how it requires redoing a website?
Re:Google and HTTP by amf12 on Tuesday July 04, 2023 @12:42PM (#36589122)
It's not just for sites which handle user data. MITM attacks are real. Non-tech people don't know what VPN, HTTP or HTTPS are.

Here's an example: a person goes to say Reddit, and clicks on a HTTP link about a new recipe. It's possible for a link to a malicious site being injected in the page. These were pretty common in developing countries.

Re:Google and HTTP by nlewycky on Tuesday July 04, 2023 @01:04PM (#36589447)
Nonsense, all sites need HTTPS. Any HTTP connection can have its contents rewritten by an middle party, so if you are using HTTP and not HTTPS then you are 100% OK with the recipient getting altered or incorrect data. If that's the case, just delete your content and serve a 404 instead since you've already stated you're OK with this.

Why do you think "handling user data" is the only reason to employ encryption? What if the website is serving up static content that seems completely fine to you or I but the user is in a legal situation where they would be in trouble for reading it? What if the user is somebody the local police are trying to frame, so the request was normal, the response was normal, but the response was replaced with something illegal so the police can arrest for possession? Why should every router on the path be able to see what I'm reading, what I'm reading web pages about medical conditions? Why do you insist that everyone should collectively make technical decisions that serve to enable this kind of thing?

This isn't hypothetical. A country once used their position of owning the local telecom to inject javascript into web pages that would DDoS another website they didn't like. See https://en.wikipedia.org/wiki/Great_Cannon .

The web moved from HTTP-over-TCP to HTTP-over-TLS because it fixes real problems. One of the common mistakes people make when thinking about security is trying to imagine the attacks themselves and then only defending against those. Your imagination is not the limit, you're up against the collective creativity of everyone else. Encrypt your stuff and remove a whole category of possible problems.

Re:Google and HTTP by jackweirdy on Tuesday July 04, 2023 @04:24PM (#36592076)
Do LAN sites need HTTPS? IE wifi router, printer, fax control panel?

I am pro-HTTP for these use cases for as long as browsers have more serious warnings against self signed certs, old SSL/TLS versions and weak algo choices than the warnings for HTTP.

Hardware deserves to be supported as long as it physically works rather than as long as its embedded TLS stays supported

Re:Google and HTTP by pixl97 on Tuesday July 04, 2023 @05:17PM (#36592601)
Depends if another device in your network is compromised.
Re:Google and HTTP by nlewycky on Tuesday July 04, 2023 @05:44PM (#36592892)
> Do LAN sites need HTTPS? IE wifi router, printer, fax control panel?

Of course. All traffic needs to be encrypted. Why must these not be encrypted?

> I am pro-HTTP for these use cases for as long as browsers have more serious warnings against self signed certs, old SSL/TLS versions and weak algo choices than the warnings for HTTP.

IMO, HTTP-over-TCP support should have been removed from all browsers years ago, solving your self-cert vs HTTP problem.

Good solutions for the LAN use case have been rather weak so far. The two categories of solutions are a) a CA for your LAN. People are OK using this for things like dev servers on localhost, but what you want is to have router that issues DHCP leases also issue IP certs for local devices. b) TLS-TOFU for self-certs. We can even do this over the public web too, but we can also treat self-signed certs on LAN vs. public web differently and report when the identity behind the IP has changed. (Generally a bad idea over the public web because we want to allow key rotation, but that might be fixable by adding multiple keys or some hack like publishing the next key into .well-known/next-key or something -- I'm riffing here.)

> Hardware deserves to be supported as long as it physically works rather than as long as its embedded TLS stays supported

Why? Or put differently, if the manufacturer has stopped providing firmware updates, they've unsupported it no matter what the rest of the world has done. Why should the rest of the world compromise security by design in order to only partially not-break a hardware device that the manufacturer doesn't support? In this one exact scenario? Maybe in the future we can provide a small ethernet-to-ethernet (or wifi-to-wifi) device that wraps a single old TLS device and provides a modern interface to it, if support is that important.

Re:Google and HTTP by jackweirdy on Tuesday July 04, 2023 @06:05PM (#36593122)
The argument I have in favour of not requiring encryption is best summarised by what you have outlined. It would require a massive industry shift towards no obvious solution with no backwards compatibility that doesn't solve anything

Until I hear a convincing story of how I will do the usual lan tasks of

- connect to my router to fiddle with settings

- see the management interface on my printer

- join my parents network and do things for them without having to explicitly trust a CA

- And most importantly, see consumers who don't understand any of those things be able to do these things all out of the box

I can't see how it is a viable expectation

I totally love encryption. It's great. But seriously: what domain will I visit to fix my pppoe settings. Who's going to control that domain, and who's going to renew the certs for it. Because if the answer we will expect consumers and SMEs to trust a certificate authority created by a factory with its own crappy security practices, I'm not sure how that's an improvement

Otherwise we are breaking things to "fix" something that doesn't "fix" anything. if someone is MITMing my lan, it doesn't matter whether my router is TLS or not. it's compromised

Re:Google and HTTP by bullen on Tuesday July 04, 2023 @12:48PM (#36589197)
It's preventing the "wrong" third parties.

Big companies and governmental branches have their own root certificates.

To remove HTTP is the biggest mistake humans have made with the internet so far.

But it will trigger a reaction that deprecates both companies and governments:

http://radiomesh.org

Edit: Loving the down vote without comment and now the whole submission is flagged.

Google really does not want HTTP around. They seem threatened by it?

Re:Google and HTTP by rednixion on Tuesday July 04, 2023 @01:34PM (#36589926)
Certificate transparency and the fact that Chrome only trusts leaf certificates that are in multiple log servers stop governments or rouge CA’s from doing a ssl mitm(or at least doing so quietly).
Re:Google and HTTP by bullen on Tuesday July 04, 2023 @01:48PM (#36590154)
Well I would love to trust that, but if you go to the main police station in Stockholm Sweden and use their WiFi they proudly show you how they can read and modify your HTTPS traffic without your device so much flinching with their root cert.
Re:Google and HTTP by bscphil on Tuesday July 04, 2023 @02:29PM (#36590769)
Upvoted simply because this claim is so astonishing. If you can back this up I implore you to provide as much technical information and proof as possible, because the PKI managers for the major browser vendors would certainly revoke certificates for this.

https://groups.google.com/a/mozilla.org/g/dev-security-polic...

Re:Google and HTTP by CyberDildonics on Friday July 07, 2023 @09:10AM (#36631194)
This person has claimed that video games like starcraft won't be playable in the future due to power constraints and that 10 gigabit networking is impossible due to using too much power (no explanation for why it already exists). They have also claimed that 2012 atom CPUs are the pinnacle of CPU design so I wouldn't invest much into thinking you will get a real explanation.
Re:Google and HTTP by bullen on Monday July 10, 2023 @09:15AM (#36665919)
I already told you to have power backup for 24+ hours for what can saturate 10Gb/s you need more than ~8x 15kg lead-acid batteries = Not practical.

25W Atom 14nm CPU is the best middle ground between 80W Xeon and 15W Jetson Nano. It is what you need to load balance saturation of 1Gb/s = Final decentralized node.

StarCraft might be playable, StarCraft 2 however will be a privilege.

Get your facts straight!

Re:Google and HTTP by CyberDildonics on Monday July 10, 2023 @10:29AM (#36666992)
Nothing you said here makes any sense at all. People are out there using 10 gigabit networking. There are benchmarks that show how slow the atom cpus are. There no power shortage. Why do you believe these ideas?
Re:Google and HTTP by bullen on Monday July 10, 2023 @05:19PM (#36673101)
You have zero arguments.

I'm talking about the future, not now.

Please link to the Atom benchmarks that show how slow they are on relevant server tasks. I remind you I'm talking about 14nm with 8-16 cores.

Re:Google and HTTP by CyberDildonics on Monday July 10, 2023 @11:11PM (#36676004)
To be clear here, you are predicting the future and in that future there is for some reason not enough power to play a game from 12 years ago, even though it can be played on a 65W AMD chip. You realize that refrigerators, space heaters and air conditioners take about 10x-30x the amount of power you are saying won't be available in the future right?

The burden of proof is on the people who make the (ridiculous) claims.

Re:Google and HTTP by bullen on Tuesday July 11, 2023 @02:31AM (#36677135)
Energy is scarce and money is infinite.

We had $1/KWh in EU this winter.

With that price you are paying almost $1 per day of running your 65W computer.

That's $30 per month just to keep the computer on during daytime.

There is no roof for how high prices or inflation can go.

Other gear are more important than entertainment, people will not consume games when they are hungry or cold.

I'm going to go out on a limb here and say that nuclear is heating the planet more than CO2, the efficiency of nuclear is 35% so for every KWh of electricity you heat the planet with 3 KWh.

3KWh that the planet has to radiate into space that did not get added during any time before.

We are slowly boiling the planet, like frogs in a casserole.

Re:Google and HTTP by CyberDildonics on Tuesday July 11, 2023 @10:53AM (#36681872)
Energy is scarce

No it is not, especially in the context of running home computers. Why do you think that?

money is infinite

No it is not.

We had $1/KWh in EU this winter.

Average price is about 0.22 Here is some actual information.

https://ec.europa.eu/eurostat/statistics-explained/index.php...

That's $30 per month just to keep the computer gaming during daytime.

No it is not. 65W is the max amount of power. 10 hours a day every day at max is still a little over $4 per month. TVs, refrigerators electric heating and air conditioning are all 20x the impact of an average computer.

I'm going to go out on a limb here and say that nuclear is heating the planet more than CO2

You should not go out on a limb for anything. You should read and stop guessing.

Where are you getting your ideas? Source something, link anything that supports what you are saying.

Re:Google and HTTP by davewiner on Tuesday July 04, 2023 @01:01PM (#36589404)
did you read the part about how https doesn't protect us from the browser vendor, ie google?

They tell us to worry about man-in-the-middle attacks that might modify content, but fail to mention that they can do it in the browser, even if you use a "secure" protocol. They are the one entity you must trust above all. No way around it.