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.
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 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.
Agree 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.
That'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.
Might 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.
I’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.
This event sounds much more realistic/common, the motivation of an ISP to save bandwidth costs is much more likely/frequent than the motivation of an ISP to monetize through ads (in addition to monthly service fees).
Where 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.
Cox Communications used to do it in California to inject JS into sites. I remember seeing little Cox popup/toast messages in the corner of other sites.
This 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
Invalid 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.
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.
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 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.
I'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
Agree 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.
That'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.
Might 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.
If 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
On 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.
That's when you connect the VPN...
I 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?
I’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...
This event sounds much more realistic/common, the motivation of an ISP to save bandwidth costs is much more likely/frequent than the motivation of an ISP to monetize through ads (in addition to monthly service fees).
Where 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.
Comcast / Xfinity in the U.S., for example:
https://www.reddit.com/r/technology/comments/9b5ikd/comcastx...
Cox Communications used to do it in California to inject JS into sites. I remember seeing little Cox popup/toast messages in the corner of other sites.
it was some mobile ISP in Russia. Maybe 6 or 8 years ago
This 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
My 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.
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.
Any fans of retrocomputing will certainly agree. Much of the plain-HTTP internet that's left is there by them and for them.
If you don't care about security, you could just use a browser which ignores invalid certificates.
Invalid 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.
Someone 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.