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

Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

lizizhikevich.github.io

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#51

Post by catchnear4321 »

Turskarama wrote: post #19
autoexec wrote: post #5

> Services on unexpected ports are more likely to be insecure than services on assigned ports. That line really surprised me. I'd have thought that somebody who knows enough to move a frequently targeted service to a different port to avoid low effort attacks/scans would know enough to use other protections, then I saw it was partly because of cheap IoT devices that have zero issues violating specifications out of th…

It doesn't surprise me _at all_. Security through obscurity doesn't work, if you have real security you wouldn't bother using another port because there's no (security) reason to do so. If someone is trying to use ports as their security measure then it's because they don't actually know how to make their API secure properly.

It still needs a name even if it is a misnomer.

Such as if you’ve ever gotten a confused note from IT that their automated health check failed to reach your internally hosted application.

Sometimes all you really need is for the low effort, high volume “white hat” to just go away. The answer for why the heath check that you didn’t ask for didn’t work is simply “security through obscurity.”

They love hearing that. It sounds clever.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#52

Post by horsawlarway »

oakwhiz wrote: post #43
fyver wrote: post #31

Earlier quoted context omitted.

You can use reverse-proxying and have several servers behind a single front one.

Reverse proxies usually require configuration changes to work. Plus they are single points of failure. Server Name Indication (SNI) is a fairly recent development as well - any apps written before that was widespread, or designed in that way, will have a unique web server for every HTTP based service that has its own separately managed certificate. Reverse proxying is less common in wild IoT devices, network applianc…

The initial RFC for SNI is 20 years old this year. It's been in OpenSSL for 19 years.

Plus - Unless the client is outside of a browser context, you can drop an nginx instance in front of the service without the service having any clue.

Throw a load balancer in front and it's probably much more robust than a single service.

Honestly - reverse proxy support is one of the more magical parts of http.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#53

Post by Am4TIfIsER0ppos »

2h wrote: post #6

Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless. Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletp…

Everyone else replying is a shill of one sort or another.

Someone might inject javascript into the page? You should not be allowing RCE anyway.

Someone might MITM? Cloudflare does this with https anyway.

Companies might spy on you? They already are. Cloudflare intercepts all the traffic going to them despite it being encrypted.

Government might spy on you? They already are. They have backdoors and frontdoors into every system.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#55

Post by BrandoElFollito »

Turskarama wrote: post #19
autoexec wrote: post #5

> Services on unexpected ports are more likely to be insecure than services on assigned ports. That line really surprised me. I'd have thought that somebody who knows enough to move a frequently targeted service to a different port to avoid low effort attacks/scans would know enough to use other protections, then I saw it was partly because of cheap IoT devices that have zero issues violating specifications out of th…

It doesn't surprise me _at all_. Security through obscurity doesn't work, if you have real security you wouldn't bother using another port because there's no (security) reason to do so. If someone is trying to use ports as their security measure then it's because they don't actually know how to make their API secure properly.

Of course it works, and can be the only protection. It just depends on your risk profile.

I can hide my service with a random key and you will never get to it. This is how a lot of data is shared when you do not have identity management.

Of course once you share this URI then the one who what it can access the data. But again, it is a choice.

Security is difficult, especially when someone jumps on without assessing their threat profile.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#56

Post by smorrebrod »

rerdavies wrote: post #47

It should be zero! Who are the 3% of web service providers providing a web service on an unencrypted port on the open internet?!

Although I admit it is a niche, retro computing web pages can be found unencrypted to allow access to ancient computers incapable of performing TLS computations.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#57

Post by account42 »

gabcoh wrote: post #38
somat wrote: post #20

Earlier quoted context omitted.

Agree, what I dislike most about https is the way it effectively has a forced expiry date. Have you ever stumbled across someones old abandoned university project page, a blast from the past with all sorts of interesting information. hopes and dreams from a bygone era. not gonna happen with https.

The https certificate “expiration” date is basically just a “fallback to treating this website as http” date. The site is still perfectly accessible and arguably still more secure than an http only site, you just have to click the scary button saying you know what you’re doing and proceed to the website treating it as though it was compromised which isn’t a big deal for the static pages you’re describing.

Besides the certifacte expiration date there are also expiration dates in the protocol itself as newer clients/servers will refuse to use older SSL/TLS versions or ciphers.

But even with "just" certificate expiration the user experience is not even close to "fall back to HTTP". Browsers won't even give you the choice to override certificate check at all with HSTS.

Then there is the fact that the move from HTTP to HTTPS changes all URLs. If only we would have had StartTLS for HTTP - and no, there is no security issue with StartTLS as you will need something like HSTS preloading anyway if you actually want to guarantee security.

Lack of backwards compatibility is absolutely a concern that the security community seems to care little about.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#58

Post by account42 »

dugite-code wrote: post #32
readthenotes1 wrote: post #30

Earlier quoted context omitted.

Keeping your certs up to date is a little bit harder than turning it on and off again every now and then

Not if you are using tools like letsencrypt, something most blogs and small university projects would readily use. Yes there may be a breaking change in the future but it's quite set and forget at this point.

Seeing as there are severs that are still running but have expired (letsencrypt) certificates, yes it is unquestionably harder.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#59

Post by account42 »

bqmjjx0kac wrote: post #8
2h wrote: post #6

Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless. Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletp…

Which part of confidentiality/integrity/authenticity is unnecessary for a static site?

The part where you require those for your ISP, a legal entity that you have a contract with and can enforce laws against, but not for Cloudflare, Netlify, Akamai, GitHub and all the cloud vendors have access and can modify this supposedly authentic and confidentional data.

Re: Stanford researchers find only 3% of HTTP runs on port 80 [pdf]

#60

Post by account42 »

Taek wrote: post #12
2h wrote: post #6

Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless. Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletp…

I don't want to pile on, but security vulnerabilities are often composed of a series of seemingly insignificant weaknesses that get chained together in highly clever ways. Anything that is accessed over http gives a potential attacker the ability to monitor activity, MitM, spread misinformation, and find potential other footholds that can be composed into a larger attack.

TLS ads a lot of complexity and with it come additonal vulnerabilities that a HTTP-based site doesn't have - e.g. most famously Heartbleed.
Post reply on HN