I have also just made my website available over http.

No need for https-exclusivity given that it's a static site serving static content and not receiving any user input.

It means that those using older, slower computers or "outdated" browsers can still view the content on my site.

Follow

@jbauer please reconsider, HTTP is an attack vector for , among others:
occrp.org/en/the-pegasus-proje

"""
A target’s web browsing can leave them open to attack without the need for them to click on a specifically-designed malicious link. This approach involves waiting for the target to visit a website that is not fully secured during their normal online activity. Once they click on a link to an unprotected site, NSO Group’s software can access the phone and trigger an infection.
"""

· · Web · 4 · 6 · 6

@jbauer absolutely. I am as furious and frustrated by this as anyone.

I want old tech to continue just working. I want things to not become obsolete for silly reasons.

But I also want journalists and activists not to be pwned by people who want to physically hurt them, and if the price for that is running HTTPS and making some old tech obsolete... well, I'll take it.

@rysiek@mastodon.technology @jbauer@bsd.network I'm just kinda wondering if the only way to allow old stuff to visit modern sites is by using an HTTPS proxy

@norm @jbauer perhaps that's a way. But there is no way to signal this to such an old device, the old device operator/user needs to know about them and use them.

@rysiek@mastodon.technology @jbauer@bsd.network like what I'm thinking is that you'd have an HTTPS to HTTP proxy inside the same internal network that the old device is connected to. The proxy would live on some server on the same network like a spare Raspberry Pi.

Obviously not as convenient as having a direct connection, but it could work...

@norm @jbauer and would somewhat mitigate the Malware-in-the-Middle attack vector, too, since the proxy *is* on your internal network. All external traffic is HTTPS still.

Me gusta.

Could be done using SOCKS5 or other default proxy set-up if supported by the old device(s) in question.

@rysiek @norm @jbauer hmm yeah back in the Netscape 4 days it had a "proxy autoconfig" file (.pac iirc) that defined how to find the proxy for various traffic. Could be useful for automatically finding the https proxy.

@eqe @rysiek @norm @jbauer for sufficiently old hardware you need a proxy anyway to add the Host: header for HTTP/1.1 compatibility. trmm.net/NeXT/#http10proxy

@th For a better view on the modern web, you can also use tenox' wrp (not really a proxy, more a re-rendering web server) or WebOne (which has an actual http proxy mode). Either needs a relatively beefy machine to run on though.

github.com/tenox7/wrp
github.com/atauenis/webone

@eqe @rysiek @norm @jbauer

@norm You still have a number of issues.

The proxy itself needs to be trusted.
If it's a passthrough proxy, rather than a caching proxy, intercept and modification can still occur.
Checksumming helps.
As does spefic malware checking.

Sadlly, the age of open unencrypted protocols passed. Several decades ago.

@jbauer @rysiek

@dredmorbius@toot.cat @jbauer@bsd.network @rysiek@mastodon.technology

The proxy itself needs to be trusted.

My solution is to have it on a local network that you control as mentioned in my other posts.

If it's a passthrough proxy, rather than a caching proxy, intercept and modification can still occur.

Modification could be useful in some cases, like allowing a page to render correctly, which is useful on old system without support for the latest standards.

I will acknowledge that it's foolish to try to use unencrypted protocols in 2021. This is more about trying to visit the web occasionally on retro devices.

@norm What are the benefits of a proxy that is directly traceable to you?

The benefits of HTTPS are:

Server authenticity is asserted.
Contents integrity is asserted.
Specific request(s) and content(s) are encrypted against third-party observation.
Specific request(s) and content(s) are encrypted against third-party injection.

Additionally, a redirect proxy (VPN or Tor for example) can obscure what clients are making what requests of a host, providing further protections against surveillance. (Vulnerable to timing-based observations, but increasing surveillance costs considerably.)

A locally-hosted proxy ... does none of this.

What possible benefits do you see?

@jbauer @rysiek

@dredmorbius@toot.cat @jbauer@bsd.network @rysiek@mastodon.technology the proxy in this use case serves more as a compatibility layer than anything security related.

If you really wanted to, you could have the local proxy connect to a VPN or whatever. Nothing would prevent that.

@norm @jbauer @rysiek

Got it. Yeah, so the proxy helps an HTTPS-only client talk to an HTTP-only server.

It doesn't provide any additional security or privacy, however.

@jbauer @rysiek That among many other things. Injecting stuff into HTTP websites is also common practice for many ISPs in the world. They'll inject some lovely ads to set of their cost :)

troyhunt.com/heres-why-your-st

@jbauer and we've known HTTP connections are abused this way at least since 2014:
citizenlab.ca/2014/08/cat-vide

In other words, *any* HTTP website or resource is a viable vector for malicious actors to use to inject malware. It has been done, and is being done, and will continue to be done.

This is of course your decision. But as a person who works with people potentially targeted... please, reconsider.

@rysiek @jbauer wouldn't enabling https-only mode or using an extension such as https-everywhere fix this for people who are in such a sensitive position?

@karmanyaahm @rysiek @jbauer

HTTPS Everywhere is, er, ambitiously named: it can't use HTTPS with sites that don't support it.

eff.org/https-everywhere

As basic security, everyone should use at least one form of content-blocking at all times: uBlock Origin, Blokada, Pi-Hole, TrackerControl, etc. And don't just install them, but understand what they do, keep them updated, and make sure they're configured properly. Some blocklists specifically target Pegasus domains:

github.com/AmnestyTech/investi

@markusl @karmanyaahm @rysiek @jbauer https-everywhere is being deprecated in favor of equivalent functionality baked into browsers.

Always avoid extensions if you can; they significantly weaken site isolation.

@Seirdy @jbauer @markusl @rysiek @karmanyaahm putting spyware on top of bloatware, sounds postmodern enough. can't wait for the blazingly fast #opensource browsers of the future. #foss #cybersecurity

@Seirdy

Could you expand on that last sentence, please? Do you mean that sites can track you by identifying a unique list of installed extensions in some way? Are there any countermeasures one can take?

@jbauer @rysiek @karmanyaahm

@markusl @jbauer @rysiek @karmanyaahm The way extensions work inherently involves weakening the content sandbox, esp. if you give an extension full access.

What's more: extensions that alter page contents are trivial to detect. In fact, CSP reporting allowed me to detect specific anti-fingerprinting addons (e.g. Canvas Fingerprinting Defender) on my site without any JS; I disabled CSP reports shortly after.

Even if you block CSP reports, you don't account for all the JS on a page that can do the same thing.

If an addon injects content, it makes itself trivially identifiable. And that's before you get into the security issues of compromising sandboxing through site/origin isolation, which content injection by its very nature violates.

@markusl @jbauer @karmanyaahm @rysiek As an experiment, try running an addon on a page with a maximally strict CSP, including a blank sandbox directive. Any functionality that breaks has the aforementioned issues.

@Seirdy whoa, thanks for the deep-ish dive! Hadn't thought about CSP reporting as a means to identify extensions.

@markusl @rysiek @jbauer

> HTTPS Everywhere is, er, ambitiously named: it can't use HTTPS with sites that don't support it.
I think OP said *also* HTTP. HTTPS should definitely be an available option for all sites

> As basic security, everyone should use at least one form of content-blocking at all times: uBlock Origin, Blokada, Pi-Hole, TrackerControl, etc.

I agree

@karmanyaahm @jbauer I would like browsers to let me say "I do not ever want cleartext HTTP requests made, ever"

@rysiek @jbauer doesn't this also affect http->https redicrects though?

@wolf480pl @jbauer it does, but only once if HSTS is deployed -- that's why HSTS is so important.

I would also need to check if browsers did not start doing HTTPS first by default. That would make all the sense.

@rysiek @jbauer if browsers do HTTPS first then it doesn't matter if you also offer HTTP. Otherwise, good point wrt. HSTS.

@wolf480pl @jbauer even if browsers do HTTPS first, it does matter if you offer HTTP, because downgrade attacks are a thing.

Say I want to Malware-in-the-Middle you. I find a site that offers content on both HTTPS and HTTP, *block* HTTPS, but let you use HTTP. If there is no HSTS, I get a nice, cleartext request to intercept and inject with my malware.

Now I need you to click such a link (which might not be hard if it's a nice blog), and mission accomplished.

@wolf480pl @jbauer what I would *really* want to see is for browsers to:
1. do HTTPS first;
2. if HTTPS is unavailable, do HTTP HEAD to get the headers and check for HSTS;
3. if HSTS present, error out; if not, fetch resource over cleartext HTTP.

@rysiek @jbauer hmm yeah should be easier to avoid vulns in header parsing than in JS

@wolf480pl @jbauer especially that in this first HTTP HEAD request the *ONLY* thing you need to parse (if present) is the HSTS header.

@rysiek @wolf480pl @jbauer retrieving HSTS headers over an insecure connection doesn't really make sense since the content in there can be (and likely is) attacker-controlled and can't be trusted

there's really nothing stopping me from messing with that header (or anything else) if i'm in the position to do a downgrade attack

@sn0w @jbauer @rysiek not necessarily, i think you can inject RSTs to perform a downgrade without being in the middle.

@wolf480pl @jbauer @rysiek you can, but this doesn't change that HTTP can't be reasonably used for anything security-related
@wolf480pl @sn0w @jbauer @rysiek you need to snoop on the traffic, to send an RST with the correct sequence number.
Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!