SSL support for TCP Sockets

[Aedda]

SSL support would allow programs like IRC to safely enter user/pass combos for instance or securely sync data between a website and in-game with less worry of data being intercepted.

Someone on IRC said this topic may have come up in the past and was deemed undoable due to needing to be written in Lua. However I found these earlier and was wondering if adding support for it could/would be possible...

http://notebook.kulchenko.com/programming/https-ssl-calls-with-lua-and-luasec

https://www.broadinstitute.org/~carneiro/software/luassl/intro.html

https://github.com/zhaozg/lua-openssl

and

http://lua-users.org/wiki/CryptographyStuff

[Xe]

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.

[Kubuxu]

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

[fnuecke]

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.

[twothe]

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

[Kubuxu]

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).

[RyanSquared]

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.

[fnuecke]

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.

[twothe]

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.

[Kubuxu]

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.

[twothe]

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.

[gjgfuj]

Some sites require encrypted connections anyway. And who cares?

[fnuecke]

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

[fnuecke]

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 >_>

[Kubuxu]

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.

[twothe]

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".

[Vexatos]

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

[cyber01]

here any solution for https?

[RyanSquared]

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

[Fingercomp]

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.

[xarses]

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?

[Kubuxu]

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

[RyanSquared]

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

[magik6k]

Maybe data card can do that?

[RyanSquared]

@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

[skyem123]

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.

[skyem123]

It's been over a year since I last looked at this, and I've recently been doing some reading. First off... Java has a built in SSLSocket, which would seem to be the solution, however OpenComputers uses SocketChannels, and there's no SSLSocketChannel, so to implement that, one would apparently need to use SSLEngine, according to http://stackoverflow.com/questions/9118367/java-nio-channels-and-tls

[SoniEx2]

Use computronics! TLS in userspace! It has cryptographic primitives which you can combine into a TLS driver!

(Honestly, if you're gonna do this, give us the cryptographic primitives and implement the TLS as a socket wrapper in the OS. It's better that way, because then clients can override the TLS support for self-signed services and such.)

[makkarpov]

Use Netty. Minecraft already uses it for networking (so there will be no external dependency), and Netty has a SSLHandler

SSLSockets cannot be used on server adequately since they are blocking. Netty provides asynchronous SSL implementation.

[SoniEx2]

Why not implement TLS as part of the OS? Why do it in Java?

[makkarpov]

Because implementing in Lua something very low-level and compilcated (there are sites that supports only RSA, only ECDSA, some of them require ECDH, only SHA1/SHA256 and so on) is a perfect way to heat up processor executing useless code.

Just use existing implementations and don't try to reinvent the wheel, especially in thing like SSL/TLS.

[SoniEx2]

Always "reinvent" the wheel, especially for things like TLS.

Also, what stops OC from just exposing the Java implementation of the cryptographic primitives to the Lua side? That way you don't need to implement the cryptographic primitives in Lua, you just need to glue them together.

[makkarpov]

Nothing, some of them are already exposed using data cards. But if we want TCP to be event-driven (and we want, somewhere around there is a ticket for data card events) we must use Netty anyway. So SSL is different from No-SSL by one line of code.

Also it's still non-trivial task to glue them together, even if you have existing crypto.

[SoniEx2]

It's not far from trivial. And it would be much better to glue them together on the Lua side because then the Lua side can add/remove cryptographic primitives and things.

[Fingercomp]

There is a Lua implementation of TLS that uses a data card and an advanced cipher. It's slow, can't be used on microcontrollers, only supports RSA, and doesn't check for certificate validity. Fixing these things would make the implementation even slower. TLS sockets should be provided by the mod.

[twothe]

Rule #1 in cryptography: don't implement it yourself. To be cryptographically secure is much more complicated than just implementing the algorithm.

I'd say implementing the Netty SSL-sockets in the background should be completely sufficient. Then you can access the whole internet without having to worry about the details.

[makkarpov]

+1 for "dont implement it yourself". +1 for "slow", I mentioned it before, it's a perfect way to waste electricity doing useless computations.

Also consider HTTPs. You have to parse HTTP in Lua if you want userspace TLS.

[SoniEx2]

HTTPS is already supported.

"Don't implement it yourself" is not a reasonable cryptography rule.

Implementing TLS in Lua would allow each program to fine-tune the TLS environment, including:

• Enable or disable certificate validation
• Enable or disable specific TLS algorithms
• Etc.

By having the native cryptographic primitives exposed as part of the default libs with little to no speed restrictions you also solve the speed and microcontroller problem.

[makkarpov]

At cost of SIGNIFICANTLY degraded performance

Exposing raw RSA to Lua is also dangerous since it is resource-consuming. That why there is no RSA in data card.

"Do not implement it yourself" is a reasonable cryptography rule. None of your fine-tune settings (except maybe cerificate validation, which can be easily configured at mod side) are really useful. And completely none of them are worth performance penalties imposed by TLS in Lua.

[makkarpov]

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".

[SoniEx2]

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.)

[makkarpov]

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

[makkarpov]

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.

[SoniEx2]

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

[SoniEx2]

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

[makkarpov]

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"

[SoniEx2]

It's a lot simpler than you think.

And RSA is not allowed in TLS 1.3.

[makkarpov]

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

[SoniEx2]

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

[makkarpov]

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

[SoniEx2]

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.