Live data from Hacker News

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

lizizhikevich.github.io

71–74 of 74 posts

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

#71
post #49

Earlier quoted context omitted.

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

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

#72
post #12

Earlier quoted context omitted.

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.

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

#73
post #43

Earlier quoted context omitted.

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.

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

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

#74

Earlier quoted context omitted.

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.

Post reply on HN