Need security.md

[JC-000]

There should be a documented non-public way to responsibly disclose security issues.

[chrisgleissner]

Thanks for raising this.

Please keep in mind the intended use of the U64 and U2 in a LAN. The network password is transmitted in clear text for both http, Telnet, and ftp. So use in a public network setting is not advised.

@GideonZ What are your thoughts. Do you think we need such a policy?

[JC-000]

If you take the machine to a place like Vintage Computer Festival where other machines are on the LAN, then the exposure risk changes, and what look like inconveniences in the form of bugs become exploitable.

[chrisgleissner]

The only way to avoid all risk is to disable the network listeners and also prevent anyone from touching your device. Any client sends the network password in clear text. So it is easy to sniff and access it.

Have you found any vulnerabilities that you would like to share or is this issue more or a theoretical nature?

[JC-000]

I have something specific in mind.

[chrisgleissner]

@JC-000 Whilst we don't have such a security.md in place, I would suggest emailing Gideon if you are certain this is a serious issue that affects our firmware and is not just of a theoretical nature.

[barryw]

Maybe the devices need an "airplane mode"?

[chrisgleissner]

@barryw That is an excellent idea! I love it. Just like the airplane mode of a smart phone, you could temporarily go completely offline. It is conceptually similar to the Master Vol which we added as global SID mixer, overriding all more finely granular SID controls.

@JC-000 Would that address your specific security concerns? Even if it does not, in terms of convenience, an airplane feature would help a lot. And it would allow users to quickly disable all remoting features of the device when they are on a public network.

[barryw]

@chrisgleissner @GideonZ I'm happy to take on the "airplane mode" if we decide to go that way. I think a connectivity kill switch is the right thing until we can get TLS implemented (I have a workspace dedicated to this and have made good progress)

[chrisgleissner]

Nice! Btw did you see how @JC-000 implemented TLS 1.3 purely on the 6510? It takes a long time though. Over 10s per request.

[barryw]

I did! That's an interesting experiment, but I'm going to run the encryption on the ESP which makes it quite usable! I'll wipe the dust off the code and start getting it into a PR.. it handles encryption of low-level sockets and layers TLS on top of that. I want to be able to build custom, encrypted binary protocols.. https is too heavy.

[JC-000]

@chrisgleissner I created a private clone repo that has one open PR and invited you to be a contributor. The advisory is linked in the PR.

[JC-000]

On the TLS demo, I have not done anything to clean it up and make it nice looking but you can load the C64 Wikipedia page and scroll through the text. I believe it works on rr-net connected to a U64E/C64U also. The reader buffers the html it into the REU as the page loads, and scrolling is pretty decent as a result. It's just cluttered with some special characters right now. With a bit of time to focus on it I might turn it into a TLS wikipedia-specific browser, but my next milestone is implementing PQC. The biggest challenge for it is actually Cloudflare, which does not follow some RFCs for their CDN service and drop connections hard at 15 seconds. More or less everything I've tried that is not behind CF works, and for many of them you don't even need the 48Mhz mode.

For ESP32 crypto you will probably find that there is not enough room to store all the CA's if you try to build a TLS offload engine. There is also no RNG active I believe. Honestly if you're going to do something outside of what an OG 64 could do then all you really need is a multiply instruction. If you had a multiply instruction then the crypto math would be massively faster and you could do it in the C64 runtime without the turbo and the multiply tables and stuff.

[chrisgleissner]

Closing this issue as we have found a viable workaround, even without security.md. Thanks for sharing @JC-000 in a private repo. You can use a similar approach in future.

However, please note that fixes will need to be merged eventually, and there is always a large delay between fixes getting merged, them reaching a release, and people flashing them. So my preference would be for you to just raise normal PRs as this drastically simplifies our ability to build and merge them.