Where possible I would highly suggest the use of luasec simply due to the fact that it is a simple wrapper around the system SSL library. It does require a system SSL library to be present however and may not work as well on less than capable operating systems (cough windows cough). It needs more research.

HTTP is handled by Java/scala. It is not Lua's lib. Handling SSL should be done Java's part.

The thing with those is that they're native libraries - meaning they'd have to be built into the native lib, which would set a precedent I'd rather not. A potentially feasible solution might be providing SSL sockets via userdata wrapped Java SSL sockets. Haven't messed with those in a while though, remember them being kind of annoying to deal with however (keystore stuff?)

If someone were to make a proof-of-concept addon card that provides SSL sockets or make a PR, there's a good chance I'd merge it. Can't promise I'll look into this soon myself.

Lua 5.3 will have native bit manipulation support. Once that is reasonably stable, pur LUA SSH libs will follow soon for sure.

I don''t think someone will create pure TLS in pure lua. Look at the size of OpenSSL codebase. It is just too much for hobby project (most projects for lua are such).

Can we not do this in Java/Scala? The networking code is already done that way.

I plan on taking a look at this later if I can to see what I can do with it.

Yeah, that'd be the most practical and consistent approach. I'm not sure off the top of my head what kind of configuration the SSL sockets need, but if the answer to that is none/minimal, it might just be a boolean/set of parameter(s) added to the existing connect method.

Doing the connection would be a simple SSLSocket instead of Socket, however when the server asks for client authentication things might get difficult. OpenComputers would need to have a valid certificate or offer an option to inject one.

My first question when confronted with this would by "Why?". OP says to ensure security in communications, which sounds a bit off considering that it in the end runs in a completely unsecured environment. Give me a moment and I add a mod to my server that will log all communication you do unencrypted and grabs all passwords you enter and sends them home.

There are two types of safe communication:

• Making sure that client and server are who they supposed to be.
• Full encryption.

The first is trivial even in Lua. Just look at Challenge–response_authentication
Second is a bit more complicated but if AES would get into OC it would also possible and simple.

On the first: yes, there are enough solutions out there that everyone can implement, and most official servers (like IRC) use them anyways.

On the second: The problem I see here is the illusion that SSL actually adds any security to OC. Keep in mind that all data you enter on your keyboard is actually sent completely unencrypted to the server, so if I want to know your password, that would be the easiest point to intercept it. Furthermore if I would be an evil server owner, I could add a mod that logs everything fully automatic. No amount of encryption added to OC could change that, because the environment it runs in is unsecured.

Now while I won't mind SSL as a feature, I see the danger that some people then actually transmit sensitive data and are later surprised if it was still stolen, despite an encrypted TCP connection.

Some sites require encrypted connections anyway. And who cares?

That's... actually a fair point. I still think it'd be tremendously useful, since some servers simply require SSL connections, but it'd certainly be a good idea to make it abundantly clear that this doesn't mean the actual input is secure, in the item name, tooltip, manual and/or API.

@Kubuxu if you're confident you can fully emulate this in Lua if/when #1307 goes through that'd probably be a more in-theme solution to this :3

who cares?

Well, it's at least worth considering ;-) But true, I suspect if someone were to make a login for OpenOS some people would use their actual password they use everywhere else, too >_>

Full connection encryption using AES wouldn't be a problem but either way it requires dedicated service.
I really don't want to know what you want to send form OC via internet that you want to encrypt it.

Well, it's at least worth considering

Thanks. According to my experience what you describe is exactly what will happen as soon as something is labeled as "secure", and a big warning sign will then decide who will get the blame if something is stolen. It takes less than a minute to add it, and would take hours if not days to clean up the mess if someone says "OpenComputers is stealing my login data".

@Kubuxu It would really mainly be for the websites that force HTTPS.

here any solution for https?

There's currently no solution for HTTPS IIRC, @cyber01

I wanted to write a Gist client. The API uses PATCH, DELETE, PUT. I can't make such requests, so I need to use a raw connection. There's currently no SSL support for sockets, but api.github.com forces HTTPS.

Not to be extra annoying, but HTTPS support is a requirement on the internet now days. The internet component is simply broken w/o it.

Would it be possible to support luasec or any other work-around option until another solution can be implmented?

HTTPS itself exists AFAIK and should work. TSL is not that easy to do.

Do you have an example? I didn't think it was.

Maybe data card can do that?

@magik6k The data card could probably set up an encrypted channel but nothing the level of SSL/TLS. It would be useful if you were to, say, experimentally recreate how TLS works but to use it as a more 'secure' feature wouldn't be valid.

In short, data_card:TLS::raspberry_pi:supercomputer

Well... some things do not work with HTTPS, such as @Vexatos's tape drive program, because it uses raw TCP sockets for some reason (and knowing @Vexatos, it's probably a good reason).

Also, having TLS as something that's on the data card is a bit silly when the internet card can do HTTPS, so TLS should be on the internet card.

And as a server owner I think that doing such computations in Lua is insane. I prefer to use my CPU for some useful tasks, not just to heat some air by executing useless code just because someone is fanatically follows the conception that "everything must be done in Lua".

Glue should be done in Lua. There's no performance degradation in glue, because it's just glue.

(Also, RSA is no longer used in TLS 1.3.)

I see, yes. Parsing TLS records, doing certificate validation, accumulating data from HMACs, etc. Totally nothing, just glue.

And since there will be no "hardware" RSA (or similar non-EC algorithms) for adequate key sizes (they are just too slow and can be easily abused) you will have to perform them in Lua.

Yeah, buffering is nothing compared to the math involved in the cryptographic primitives.

Your point is moot - even OpenSSL already limits key sizes.

But 4096-rsa is still too slow to expose api for it. And TLS specs is pretty complex, not just "1) Make TCP connection 2) Encrypt everything inside"

It's a lot simpler than you think.

And RSA is not allowed in TLS 1.3.

Ah, I forgot, the whole internet is now on TLS 1.3

Also RSA is only used for the key exchange and signature bits. TLS uses block and stream ciphers for the actual data.

Ok, if you really want TLS in Lua — just do it. But Netty is easier, trust me.

https://witches.town/@SoniEx2/98952967434798305

Crypto should be secure. The best way to do that is to avoid monolithic crypto. Single point of failure and all that.

You point makes no sense.

Some of SSL/TLS flaws were protocol flaws (such as compression and padding oracles). Modularity don't help here.
Some of SSL/TLS flaws were flaws in protocol implementation (such as Heartbleed). You need to fix module/part (which is equally hard or easy) or just disable it (which you can do even in non-modularized crypto).
None of SSL/TLS flaws were flaws in cryptographic primitives.

Modules don't help at all. Again, I see no other people that will agree that SSL/TLS should be implemented in Lua. So go and implement it.

And Java SSL core is much more widely audited and maintained than your handmade SSL implementation.

And there's still nothing wrong with reimplementing crypto. I do not trust monolithic systems.

I do not trust monolithic systems.

You mean like Linux? That's a monolithic kernel.

And it's full of bugs. I also don't trust systemd.

uhh... While it's possible to do TLS in Lua, it's not practical.
Even if it was somewhat useable, which apparently it is? Then, you could use it if you wanted to.

I think external protocol stuff such as TLS and HTTP(S) should be handled as much as possible using the Internet Card, for everyone's sanity. I'm willing to suspend my disbelief there. I actually think (unrelated to this) that some more protocols should be supported on the Internet Card, mainly because they are so impractical for a Lua implementation.

I do not trust monolithic systems.

This is your personal problem. If you don't trust — implement your own (spoiler: 99% probability that it will contain much more bugs and flaws than original). Don't try to push your reimplementation as default (and don't try to remove HTTP from internet card, this is also insane, but for other reasons).

We need more crypto implementations. And you don't need HTTP on the internet card.

I need HTTP on the internet card because I want to restrict my players from sending arbitrary shit over the internet. This implies that HTTP will be formed and parsed on the internet card.

We shouldn't have HTTP on the internet card exactly because of ppl like you.

Luckily it seems that things aren't going to change, so security restrictions will be still in-place.

Why L3 then? Expose raw L2 access and form IP/TCP packets from Lua.

Well yes that's an idea I had - turn OC into an L2TP daemon, with the OC computers being part of a hamachi-like VPN.

Could you please take your discussion somewhere else?

uhh... @SoniEx2, this discussion has strayed too far from TLS support, I feel like it's better if this issue isn't derailed. ^^;;;;

Sorry.

internet card can make http requests to https endpoints. we won't be adding tls sockets. this could be done as an addon if anyone still wants this