5 ms·
What’s on HTTP?
- deleted 7mo ago[deleted]
- swordmem 7mo ago[dead]
- superkuh 7mo agoHTTP 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 much changing and too much complexity. From the software of the user to the software of the webserver. Which is to say, HTTP is not some "ancient" tech like an analog television. It is a modern technology used today doing things that HTTPS can't.
- tryauuum 7mo agoI'd rather have some expired cert than http I saw once my ISP injecting javascript ads into http traffic and the horror is with me forever
- miladyincontrol 7mo agoAgree strongly. An expired cert is better than no cert. Also would argue maintenance is only as complicated as you make it for yourself. Countless people keep patched, secure, https web servers running with minimal effort. If its somehow effort, introspect some on why you are somehow making so much work for yourself.
- superkuh 7mo agoMight be a bit of each of us touching different ends of the elephant. To be clear I am talking about long timespans. Lets Encrypt hasn't even existed for a full decade yet. During that time it's dropped support entirely for the original acme protocol. During that time it's root certs have expired at least twice (only those I remember where it caused issues in older software). And that's ignoring the churn in acme/acme2 clients and specific OS/Distro cert choice issues and browser CA issues. Saying that there's no trouble with HTTPS must be coming from experiences on short timescales (ie, a few years). HTTP/3 already doesn't allow anything but CA TLS only. It won't be too long before they no longer allow you to click through CA TLS warnings. If human people want things to be on the web for long time periods those things should be served HTTP+HTTPS.
- Ferret7446 7mo agoIf you can't keep your site's certs working, I don't have much faith you can keep your server working. Maintenance is required in the face of entropy
- pastage 7mo agoThere is some kind of middle ground here.. My first HTML file still renders like it did on Mosaic. The HTTP server I used back then still works today 35 years later without maintenance. I do agree that HTTPS is a simple solution but there is too much cargo cult around it. Honestly I do not see the use to maintain everything published if you follow sane practices. EDIT: I have 15 year old things at work that do not compile, you have to maintain it for sure, biggest problem is cryptography. I am not sure that unstable tech should be part of the application ever.
- hexfran 7mo agoUnless 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're talking applications that don't actively listen on the internet that's fine, and I would agree that we should have complete software that just works. But a webserver, unless it's for personal/home use, it's on the internet and I don't see how it could work for 35 years without any update/change
- pocksuppet 7mo agoThat's no use when your automated registrar stops working in 3 years because it went out of business or changed protocols. Let's Encrypt has been an outlier.
- deleted 7mo ago[deleted]
- Telaneo 7mo agoOn the one hand, I agree with you given that state of the world. On the other hand, that state of the world shouldn't exist. It's incredible to me that it's not illegal.
- TZubiri 7mo agoI thought that was a one time thing in a 3rd world country blown out of proportion into myth status. Would you mind sharing what ISP it was and what time period this was in?
- pixl97 7mo agoWhere as my ISP did not put in ads, they did inject messages such as maintenance was going to occur and did things like redirect bad dns to their own search. Also ISPs were monitoring and selling browsing data years ago.
- tryauuum 7mo agoit was some mobile ISP in Russia. Maybe 6 or 8 years ago
- rcakebread 7mo agoComcast / Xfinity in the U.S., for example: https://www.reddit.com/r/technology/comments/9b5ikd/comcastxfinity_is_injecting_594_lines_of_code/ https://www.reddit.com/r/technology/comments/9b5ikd/comcastx...
- fushihara 7mo agoI’m not sure whether this applies globally, but in Japan, around 2015, some mobile carriers deployed a “traffic optimization” feature that would lossily compress images in transit. On the platforms of NTT Docomo and KDDI (au), users could opt out of this behavior. However, with SoftBank, it could not be disabled, which led to controversy. As you might expect, this caused issues—since the image data was modified, the hash values changed. As a result, some game apps detected downloaded image files as corrupted and failed to load them properly. Needless to say, this was effectively a man-in-the-middle attack, so it did not work over HTTPS. Within a couple of years, the feature seems to have been quietly discontinued. There were also concerns that this might violate the secrecy of communications, but at least the government authorities responsible for telecommunications did not take any concrete action against it. There is a Japanese Wikipedia article about this: https://ja.wikipedia.org/wiki/%E9%80%9A%E4%BF%A1%E3%81%AE%E6%9C%80%E9%81%A9%E5%8C%96 https://ja.wikipedia.org/wiki/%E9%80%9A%E4%BF%A1%E3%81%AE%E6...
- userbinator 7mo agoThat's when you connect the VPN...
- Ferret7446 7mo agoThis is such a weird framing. HTTPS is HTTP. TLS is at a different layer of the network stack. You may as well say HTTP through a proxy is better or worse than HTTP through a VPN; all of those statements are equally nonsensical. You are simply arguing that insecure network requests require less work. Which is obviously true. TLS did not appear out of nothing. Much effort was expended to create it, and there's a reason
- ericpauley 7mo agoMy thoughts exactly. By this logic both are fragile because they run over lossy wireless networks. The composability of TLS/HTTP is really a beautiful thing.
- cellularmitosis 7mo agoAny fans of retrocomputing will certainly agree. Much of the plain-HTTP internet that's left is there by them and for them.
- Suzuran 7mo agoBut, as we learned with the telnet filter going into place, we exist on the network at the pleasure of everyone else. Their concerns must come before ours. The needs of the many outweigh the needs of the few.
- elixx 7mo agoThat explains why I've been using this to find all the cool stuff :) https://whatsonhttp.com/votes https://whatsonhttp.com/votes
- Gigachad 7mo agoIf you don't care about security, you could just use a browser which ignores invalid certificates.
- toast0 7mo agoInvalid certificates are one thing, and you can probably click through that. But maybe your older browser tops out at TLS 1.0, and servers don't offer that anymore (I think the credit card PCI cert discourages it) or maybe your older browser can't do ECC certs and the server you want to talk to only has an ECC cert. Or maybe your older server only speaks TLS 1.0 and that's not cool anymore. Or it could only use sha1 certs, so it can't get a current cert. When I can, I like to server http and https, and serve the favicon with HTTPS and use HSTS to induce current clients to use https for everything. Finally, a use for the favicon.
- Dylan16807 7mo agoSomeone with an older browser can update the browser outside of very niche situations. I have little concern for that use case. If a server can't do TLS 1.2 from 2008 I question how it's still stable and unhacked more than anything.
- forgotmypw17 7mo agoAgree 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.
- Suzuran 7mo agoUsing 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.
- forgotmypw17 7mo agoThis 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.
- tryauuum 7mo ago[flagged]
- unit149 7mo ago[dead]
- paulnpace 7mo agoNot very useful when most of the pages are default web server pages.
- elliot07 7mo agoThe 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.
- elixx 7mo agoThe 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.
- Shangdi63046 7mo ago[dead]
- HectorMallar73 7mo ago[dead]
- gethwhunter34 7mo ago[flagged]
- mnot 7mo agoHTTP only is fundamentally disrespectful to your users. It places your needs above theirs. It assumes that your threat model is the same as theirs. There is no excuse for it in 2026.
- 0x000xca0xfe 7mo agoHTTP is still the best solution for intranet sites... as long as you cannot run your own fully local CA as hassle-free as DHCP, HTTP will never die.
- echoangle 7mo agoCan't you get certificates by doing DNS challenges and use those certificates internally? If you don't have to be completely airgapped, doing the DNS challenges shouldn't be too hard.
- Suzuran 7mo agoIt 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.
- echoangle 7mo agoI 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.
- 0x000xca0xfe 7mo ago
- hrimfaxi 7mo agoWould 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?
- elixx 7mo agoI 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.