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

What’s on HTTP?

whatsonhttp.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: What’s on HTTP?

#51

Post by elixx »

elliot07 wrote: post #22
paulnpace wrote: post #9

Not very useful when most of the pages are default web server pages.

The author should check to see if the HTTP response body contains "nginx" or "apache" and just filter those out. Seems like at least 50% of what I'm seeing. Also would be nice if there was a hotlink to view the original site directly from the index page.

The search page lets you add multiple exclude filters to the aggregation pipeline. So as you filter common strings, the interesting results bubble to the top.

If you click the image it should take you to an info page on the service.

Re: What’s on HTTP?

#52

Post by elixx »

hrimfaxi wrote: post #50

Would be interested in more details on how this was built. The title of the page "VibeScan Tuner" seems to suggest this was vibecoded but is this actually crawling through IP space or hitting something like shodan?

I plan to do a write-up on the architecture and journey. It did start as a vibe coding experiment, and quickly evolved into a Shodan-like screenshotting OSINT thing. Agents generate random IP addresses, check for HTTP, and attempt to screenshot. If a screenshot is taken, then it becomes a 'result' submitted to the backend.

Re: What’s on HTTP?

#53

Post by Suzuran »

echoangle wrote: post #41
Suzuran wrote: post #39

Earlier quoted context omitted.

It is my understanding that DNS challenges are discouraged and/or being deprecated due to the challenge results being less trustworthy than more stringent verification methods. There is also the operational overhead that arises as SSL certificate lifetimes shorten; It is my understanding that there is now a case being made for SSL certificate lifetimes shorter than 24 hours.

I don’t know about the DNS challenge being discouraged, do you have something to read up on that? As far as I know it’s the only common way to get a wildcard cert. And also the lifetime isn’t a problem in the setup I described, the internal server that uses the cert can do the dns challenge so it can get a new cert whenever it wants. It only needs to be able to access the DNS api.

I must correct myself; The DNS challenge is indeed being discouraged in the future, but it is because the DNS-01 challenge is being replaced by the DNS-PERSIST-01 challenge which addresses deficiencies in DNS-01.

The trust and security issues associated with maintaining intranet resources vs. outsourcing to a dedicated professional cloud service provider remain, but are not related to whether any SSL certificates used are issued through DNS-based verification or not.

Re: What’s on HTTP?

#54

Post by Suzuran »

forgotmypw17 wrote: post #25
superkuh wrote: post #4

HTTP is incomparibly less fragile than HTTPS which is why HTTP+HTTPS is such a great solution for websites made by human persons for human persons. Lets be clear, corporate or institutional persons using HTTPS alone is fine and reasonable. But for human use cases HTTP+HTTPS gets you the best of both worlds. No HTTPS cert system ever survives longer than a few years without human input/maintainence. There's just too m…

Agree 100%. HTTP is much more accessible, and HTTPS has more failure modes. When I want to ensure that someone can read my content, I offer both.

Using HTTP does not guarantee your content can be read, since it can be modified in transit. Your content could be replaced entirely and you would never know unless someone reported it to you.

Re: What’s on HTTP?

#55

Post by echoangle »

0x000xca0xfe wrote: post #48
echoangle wrote: post #47

Earlier quoted context omitted.

> IMO it would be great to have your home router act as a local CA that can only issue certificates for .local domains and have that trusted per default by user agents. Would make smart home stuff a lot better than the current situation... How would you talk to the router and make sure the communication is actually with the router and not someone else? The browser/lightbulb comes with trusted CAs preinstalled, but th…

In the case of WiFi, you use a password and WPA2? Sure, if someone knows your WiFi password they could set up an "evil" router close to your house with the same SSID and credentials, or they could break into your house and install LAN wiretaps, but c'mon, if you are this paranoid you probably don't even have a smartphone in the first place.

Do you mean that you don’t need a way to verify the routers identity on the local network because it is already protected by a password?

Firstly, I don’t think that’s true because you add a lot of sketchy and unknown devices to your network over time (guests, streaming stick, computer with preinstalled OS…) so I wouldn’t trust every device in my WiFi.

And also, if you do trust your network, you don’t really need https inside it, right?

Re: What’s on HTTP?

#56

Post by forgotmypw17 »

Suzuran wrote: post #54
forgotmypw17 wrote: post #25

Earlier quoted context omitted.

Agree 100%. HTTP is much more accessible, and HTTPS has more failure modes. When I want to ensure that someone can read my content, I offer both.

Using HTTP does not guarantee your content can be read, since it can be modified in transit. Your content could be replaced entirely and you would never know unless someone reported it to you.

This is true, and is a real failure mode of HTTP.

Where I live, and for people with older devices, this happens much less frequently than the HTTPS failure modes of unsupported browsers.

Re: What’s on HTTP?

#57

Post by Ferret7446 »

superkuh wrote: post #44
hexfran wrote: post #34

Earlier quoted context omitted.

Unless I'm misunderstanding your point, your HTTP server from 35 years ago is still working today without any maintenance? Does that mean no security patching and no updates for bugfixes? or does "no maintenance" means something else I'm missing? I find it difficult to discuss these topics when comments like these pretend that you can leave your system exposed on the internet for years without any maintenance. If we'…

Static html webservers don't really have any need for security patching or bugfixes constantly like dynamic complex stuff. They literally can just live forever. The sites themselves are just files. Not applications.

I hate to break it to you, but HTTP servers (what is an html server) absolutely can have all manner of fun exploits, like RCE.
Post reply on HN