Plug in crypto

[larroy]

SSL should be plug in in the protocol / message logic in a matter that is as isolated as possible, so we are able to easily choose SSL implementation.

[jewel]

Is this still necessary? OpenSSL does everything needed and is portable to all platforms, and has a BSD-style license. It's also very widely used in open source projects.

Obviously if it's easy to make the SSL implementation pluggable then there is no harm, but each library might have its own unique way of dealing with non-socket transports (like uTP) and event-driven code.

[cachapa]

I agree with Steven.

Making everything pluggable will increase code complexity and
implementation time.

I suggest going for basic functionality first, and add more complex
features once the basic system is running.
It shouldn't be a problem if we keep to a clean architecture.

Daniel Cachapa
Sent from a mobile device
On 5 Feb 2014 14:00, "Jewel" notifications@github.com wrote:

Is this still necessary? OpenSSL does everything needed and is portable to
all platforms, and has a BSD-style license. It's also very widely used in
open source projects.

Obviously if it's easy to make the SSL implementation pluggable then there
is no harm, but each library might have its own unique way of dealing with
non-socket transports (like uTP) and event-driven code.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-34163397
.

[larroy]

Maybe I wrote in a way that was confusing. I have no problem against OpenSSL and I think Steven is the most knowledgeable for this, what I meant is that AFAIK OpenSSL can be made to encrypt and decript from and to a BIO buffer without interacting with any filedescriptors, my point is that the encryption part should be relegated to a few functions in a handful of places instead of using OpenSSL types and stuff all around. I think this should be possible, or at least investigated with this in mind.

[larroy]

I had a brief look at this, I hope we can do something similar. I think if we use libuv we should avoid dealing with fds directly.

https://gist.github.com/larroy/8596922

[jewel]

Ah, sorry @larroy. I misunderstood you. It makes sense to isolate the SSL code and what you have looks great.

We definitely can't have OpenSSL deal with FDs, otherwise TLS-over-uTP won't work. Once I'm done with switching the protocol spec to SRP, we'll need to support using the wire protocol over the following:

• plain-text over TCP (for the tracker)
• TLS over TCP
• TLS over uTP