Stanford researchers find only 3% of HTTP runs on port 80 [pdf] | Hacker News Reader

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

lizizhikevich.github.io

75 pointsdata_wiz71 comments

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 believe the intention for most hosts is to keep the service secret by running it on a non standard port.

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 appliances, and certain kinds of enterprise/line-of-business apps... Surprisingly Microsoft IIS seems to be an exception in that area

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.

You're assuming that people are going to use the smartest "best practice" way to do things from your perspective. This is not often what actually happens. It takes forever for people to realize that they should re-architect things to work like this, and that there are benefits to doing so. If you're able to have this happen in a production environment, with no conflicts with other things or other people around you, count yourself lucky...

>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,

Actually you can bind to the same port on different addresses. For loopback you have the entirety of 127.x.x.x

Or it's just that the let's encrypt topic and https per Default and getting down ranked on Google when using http makes 80 just a really really bad option.

My company blocks port 80 globally and I only learned about it through an internal service I configures. Which shows how little normal day to day traffic is http and port 80.

Also when the https topic came up, quite a lot of big hosters (shops, crms, website hosting) started to give you https which was NOT normal before.

> port 80 is very much a privileged port that most applications don’t have permission to host on

setcap 'cap_net_bind_service=+ep' /path/to/program

But yes, until like the last 10 years or so. Also while it's possible nobody knows this information.

More interestingly, port 7475 (which is the most popular port besides 80 and 443) is set top boxes watching TV.

Windows has long had the capability to share TCP ports between applications: https://learn.microsoft.com/en-us/dotnet/framework/wcf/featu...

> 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 the box.

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.

I guess that's true, but that's not a security reason.

Sure it is. Running on a nonstandard port is absolutely as adequate of a security measure as locking a screen door. But it does filter out a fair number of probes, and reducing the number of probes does increase your security.

So it's like locking the screen door in front of your reinforced, deadbolted door. Some people will try the screen door, find it locked, and move on. It doesn't do a lot, but it's not entirely worthless, either.

> 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.

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.

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.

It's not the sysadmin but the app/dev that is setting the port. When they do that, they are not intending for the public at large to find it easily and use it and services like that get less attention and care. A lot of data breaches happen for example by elastic's restful api being exposed because people don't change the defaults.

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...

Remember, the 'S' in IoT stands for 'security'.

FYI HTTP traffic in the title specifically refers to unencrypted HTTP traffic. From the abstract:

> only 3% of HTTP and 6% of TLS services run on ports 80 and 443, respectively

I imagine the numbers would be a lot more extreme if you also somehow included non-public facing endpoints.

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 bulletproof safe to guard a stick of gum. Think critically people.

I respectfully disagree that verifying your domain is pointless. Without proper verification, you leave yourself vulnerable to a range of risks, such as man-in-the-middle attacks and DNS spoofing. These attacks can allow bad actors to intercept your web traffic and inject malware into content or modify it. Recent security breaches have highlighted the importance of domain verification, and I believe that all users should take steps to verify their domains, such as implementing SSL/TLS certificates or using a domain verification service.

And additionally I would't want anyone on my network path to be able to read what data I exchange - even if it is a static site.

That’s a valid concern too. For a lot of static sites I visit, I don’t particularly care if people know I visit them as I live a boring life. My primary concern is malware and verifying identity.

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.

Static sites serving on a local network that is never exposed to the internet.

HTTPS improves security even for a static site because it prevents an ISP or middleman from injecting ads (or worse) into the page.

It also increases privacy because the contents of the traffic can not be observed by third parties.

Right, but for a static site that’s publicly accessible, even HTTPS leaks the requested URL, any listener can go fetch that page themselves to see the contents.

> even HTTPS leaks the requested URL

It does not. In the olden days the host name was leaked, but with SNI even that is gone. Anything past the first "/" is never and was never sent in plaintext in HTTPS

Most public web sites leak information about page accesses to anyone who can count bytes.

What kind of attack are you describing?

Count how many bytes of TCP traffic you see. Measure the size of each web page on the (public static) website.

The host name is still leaked, SNI is not encrypted and ESNI is still not mandatory in TLS 1.3.

> host name was leaked, but with SNI even that is gone

nope, you can still see it perfectly fine:

https://tlshello.agwa.name/

please don't spread misinformation.

ESNI*

OK, now name at least two public servers that use that. I will wait...

HTTPS does not leak the requested URL to servers between the client and the server.

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.

TLS doesn't add that much complexity unless you're actually writing your own handshake code.

> with it come additonal vulnerabilities that a HTTP-based site doesn't have

This strikes me as being a very strange point to make. HTTP includes no security whatsoever. HTTPS includes quite a lot of security. HTTPS may have vulnerabilities, but even so it's still certainly far more secure than HTTP.

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.

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.

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

That's not how that works!

If servers have an 80% survival chance, and a 95% certificate renewal chance, you'll only see the servers that are running with expired certs. You won't see the inverse.

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.

What scaring? Chrome shows a gray "not secure" and firefox has a crossed out padlock. That seems understated to me.

If you're talking about certificate error pages, then yeah there's room for improvement. Not every site needs the same level of warning there. But caution makes sense as a default. Something went wrong.

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.

Any browser that actively prevents viewing an HTTP site is not fit for purpose. Set secure defaults, absolutely. Show scary warning pages if you insist. But don't prevent legitimate activity entirely.

I used to think like this, but then I read this:

Troy Hunt: Here's Why Your Static Website Needs HTTPS https://www.troyhunt.com/heres-why-your-static-website-needs...

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.

What would you propose then?

Specifically? Firefox to stop bitching that I enter my passwords into unencrypted pages on my local network. Browsers halt or even reverse their plans of deprecating unencrypted transport. Browsers stop bitching about loading unencrypted static resources on an encrypted page.

Generally? Everyone I accused of being shills off the "everything encrypted" bandwagon. If you want to encrypt your websites go ahead. You don't have to believe my unhinged conspiracies from earlier.

> Browsers stop bitching about loading unencrypted static resources on an encrypted page.

I tend to agree with you on other points but that one is a weird take. If I deliberately visit an https page I want to be reasonably confident that it wasn't tampered with and that I'm not leaking information.

Allowing loading http resources in an https context breaks that trust. Scripts may be tampered with. The website URL is leaked via the referer. Cookies might be leaked.

Note: Mitigations for all those worries do exist. Cookies can be flagged secure-only. Referer can be stopped using CORS, etc. But they all need the developer to be proactive about it and, for the most part, they aren't.

This is expected right, HTTP is not only used for human consumable web applications but for API servers as well

The bulk of these would just be embedded devices running multiple API services, like port 7547 highlighted in the article is your typical TR-069 service running on most consumer internet routers

I would argue most non-API/non embedded devices web applications would still be running on 80 and 443

https://github.com/stanford-esrg/lzr

And I seem to hit 100% of them, going to get RSI from all the times I have to click accept the risk and continue.

Is it because of web pages or APIs?

Most web APIs will run on something else.

This is good right?

Maybe not so great. I imagine a good portion of these are services being run with development configuration, which could indicate that people aren't running a more robust configuration with a reverse proxy on 443 pointing to 80 behind a firewall.

It is a neat fact, but nothing specifically good or bad.

It should be zero!

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

This is discussed in the article.

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.

Reply on news.ycombinator.com