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

31–40 of 74 posts

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

#31

Post by fyver »

extheat wrote: post #14

At first this seemed surprising. Until you think about it more in-depth, port 80 is very much a privileged port that most applications don’t have permission to host on. Additionally, servers typically can have multiple HTTP services running in parallel and since you obviously can’t run two separate servers on the same port, it makes sense to avoid this conflict by running services on specialized ports. I don’t believ…

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

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

#32

Post by dugite-code »

readthenotes1 wrote: post #30
Dylan16807 wrote: post #24

Earlier quoted context omitted.

Those pages are abandoned, but the servers aren't abandoned. The same person keeping it running should be able to update certs just fine.

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.

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

#33

Post by [deleted] »

extheat wrote: post #14

At first this seemed surprising. Until you think about it more in-depth, port 80 is very much a privileged port that most applications don’t have permission to host on. Additionally, servers typically can have multiple HTTP services running in parallel and since you obviously can’t run two separate servers on the same port, it makes sense to avoid this conflict by running services on specialized ports. I don’t believ…

[deleted]

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

#34

Post by autoexec »

0cf8612b2e1e wrote: post #23
Turskarama wrote: post #19

Earlier quoted context omitted.

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.

>if you have real security you wouldn't bother using another port because there's no (security) reason to do so. Strong disagree with that. If you do something as simple as moving SSH to a different port, the number of drive-by attacks will drop enormously. Raises the signal to noise of all connection attempts in the logs.

SSH is what came to mind right away. The bots never sleep and will happily hammer at your server and fill your logs all day. I'd never depend on a new port as the only protection though. One man's security through obscurity is another man's defense in depth.

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

#35

Post by vbezhenar »

Dylan16807 wrote: post #29
vbezhenar wrote: post #28

Earlier quoted context omitted.

My Chrome does not allow me to visit HTTP page. Yours will do the same soon.

Why doesn't yours? What do you mean by "soon"? I just tried http://example.com/ in chrome canary and it's the same. Edit: Okay, I found the "Always use secure connections" setting, but that has been around for a while. And it doesn't actually stop me, it asks. Also downloads are or will be blocked on http but that's not too bad of an idea.

An invalid certificate also doesn't technically stops you and just asks if you really want to proceed.

By "soon" I mean that this particular behavior surely will be the default one. Here's old blog post: https://blog.chromium.org/2021/03/a-safer-default-for-naviga...

And quote from it: "HTTPS protects users by encrypting traffic sent over the network, so that sensitive information users enter on websites cannot be intercepted or modified by attackers or eavesdroppers. Chrome is invested in ensuring that HTTPS is the default protocol for the web, and this change is one more step towards ensuring Chrome always uses secure connections by default."

I think that the direction is obvious.

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

#36

Post by bfung »

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.

> Security through obscurity doesn't work

Going to echo a sibling comment -

This catchphrase may help people who know very little about security be a bit better.

But to completely throw it out is counter to security’s goals.

Obscurity can help reduce the surface area of attacks, but shouldn’t be used as the exclusive tool to secure something.

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

#38

Post by gabcoh »

somat wrote: post #20
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…

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.

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

#39

Post by pugworthy »

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…

One reason (at least in the past) to use upper ports for web servers at least is when you want to run a server, don't have root permission to use 80, so you pick 8000, 8080, 8088, etc. And you think maybe you're clever and use 8089...

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

#40

Post by Turskarama »

0cf8612b2e1e wrote: post #23
Turskarama wrote: post #19

Earlier quoted context omitted.

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.

>if you have real security you wouldn't bother using another port because there's no (security) reason to do so. Strong disagree with that. If you do something as simple as moving SSH to a different port, the number of drive-by attacks will drop enormously. Raises the signal to noise of all connection attempts in the logs.

I guess that's true, but that's not a security reason.
Post reply on HN