Hacker News Reader

Comment by monoideism | Hacker News Reader

I'd love to try it out, but I'm not downloading an executable from an `http` URL.

Edit: I hope the downvotes are because it supports `https` (just not by default, thanks to progman32 for correcting me) and not because you think that not wanting to download an executable over an open connection is an unreasonable thing.

View on HN

How is downloading a executable over https safer? It mitigates man-in-the-middle attacks that could modify the compressed artefact on the fly, but that's possibly the least likely attack on a download imaginable. It's far more likely that an attacker would try to replace the file on the server (that way they can also change and documentation around the file, like the reported MD5/SHA hash you might use to check the file is correct). Why would you happily download that over https?

If you're security conscious enough to not download random executables over http then you really should be aware that it's 99% as dangerous to download them over any link.

On most networks, anyone else on the same subnet as your IP can hijack your connection using ARP spoofing and send you whatever they want if you're connecting over Http instead of HTTPS. That's usually a lot easier to pull off than compromising the server and replacing the content there.

Something to think about for anyone still putting Google and Amazon devices on the same WiFi network as their phone and other PCs.

Ok. Don't.

Looking a gift horse in the mouth?

You would download an executable over an unencrypted connection? Whether it's free or not?

That’s what digital signatures are for. So yes.

Fair enough, I gladly use apt for the same reason. But I mean download unsigned executables over an unencrypted connection, like this site is by default. You do it?

yes. it's amusing how many people confuse transport layer security with application layer security.

I've published signed debian packages to PPAs, so I'm well aware.

My question was in relation to a unsigned executable on an unencrypted http site, as the OP site loads by default. Would you download and run one?

I'd wager that a large number of the system integrators, firmware engineers and random developers scattered throughout the production chains of most of the hardware and some of the software that you're currently using have run completely untested code in scenarios orders of magnitude more hair-raising than this.

The same is probably equivalently applicable to the hardware that was used to compile the compiler that compiled the compiler that compiled the compiler that you're using.

It's a good point.

I got: http://www.spectrum-soft.com/download/mc12cd.zip sha3-256: 1e9c7d1ec04019446fa448fec74af36f53eaf6508def75068eb32ae0d7f5109a

Not sure what the drama is about... The installer is clean.

https://www.virustotal.com/gui/file/773a060c5c824f6c47352dea...

Haha, good one!

While it's theoretically possible that a hostile party could modify the package in-transit over HTTP/TCP, it seems far more likely that the hacked package would be placed on the "legit-looking" webserver (by hacking the webserver). In this case, looking to the SSL transport layer as any kind of credibility enhancement to the unsigned binary is worse than ignoring it.

Therefore, an unsigned binary is an unsigned binary, no matter the transport mechanism. I agree that distributing unsigned binaries is poor security practice, but I also think that it is dangerous to think that the transport of an unsigned binary over an SSL connection gives it any credibility.

So.. you haven't heard of automated MITM executable-patching (infecting) solutions? I believe I read about them a couple of years ago.

Once implemented, it's much easier than hacking servers and more convenient to do targeted, semi-targeted, local network/cafe script-kiddie attacks, without it being easily detected. Unfortunately for attackers, these days people don't download and run unverified executables as often, especially over http, so you may need lots of patience if you want do infect a specific person.

I covered that in the portion of the comment where I mentioned http/tcp

I would really love some data (or good reasoning) on how server attacks are overwhelmingly more likely, so much so that the false security impression increases risk.

MITM executable patching attacks are not theoretical. AFAIU, the first hit on "mitm executable infection" [1] and an interceptor (ARP/wifi/whatever) is all a script kiddie needs.

[1] https://n0where.net/mitm-pe-file-infector-peinjector

To me, the fact that the server being exploited to deliver bad binaries is a possibility is reason enough to be cautious, and to therefore not regard them with any more credibility than if they were delivered over unencrypted http.

How do you obtain an trusted signature over http?

Site supports https.

You could spin up a virtual machine and try it out on there.

Reply on news.ycombinator.com