TLS Jack ($50)

[MaddieM4]

Create a TLS Jack based on the TCP Jack.

[MaddieM4]

Bounty is $50.

http://www.freedomsponsors.org/core/issue/142/tls-jack

---

(copied from acceptance criteria)

Jack that works like the TCP jack, only with transport-layer protection via TLS. Useful for blinding the addresses and edges of EJTP frames.

Should have jack types “tls” and “tls4”, for IPv6 and IPv4, respectively.

You may generalize code out of the TCP module to whatever degree you find appropriate.

[MoritzS]

Since I'm working on this, I have some questions that in my opinion are design decisions:

• TLS does not work as intended if you don't use any certificate at all. It will work, but I think that's not what we want. So these questions are related to the certificates.
  • Where should the path of the certificates be stored? Right now, I have to options in my mind: 1. Put it into the interface list, among host, port, and so on, since every interface may have different certificates or 2. Use ejtp.identity to provide certificate information.
  • Another problem with certificates is, that if you use them, you will quite likely make sure to validate them. So should the TLS jack validate for host and port or should it have some special Key Usages?
  • Another thing that comes along with validation is the thing with server and client certificates. Do we want do make a difference between clients and servers? If so, we need the option to make a Jack read only (hence it will only be server) or write only (it will only be client) (#66 deals with that)
• right now I'm considering using python's builtin ssl library. It was implemented in 2.6, I think that should be ok. The actual question is: Should the module just throw a NotImplementedError if you try to use it on platforms that don't have ssl support (e.g. some Windows versions without openssl)?

[MaddieM4]

Good questions, and tough ones. I don't have all the answers yet, and some of them will probably hinge on "jack reform" a la #66 happening.

• Put it in the identity, I think. I'm not sure we want to publicize the local path to the certificate via interface list, something about that just seems icky/an invitation to exploits. We already store private information in identities anyways for any asymmetric key encryptor, so the stack is already built with that as a concern.
• Jack should validate.
• In a perfect world, by default a TLS jack would act like a client, and be able to receive messages over the connections it makes to servers. I think this will be possible, eventually, thanks to some planned upgrades to the router model, which will make it much more extensible on the fly. Until then, all TLS jacks will have to be able to work as both client and server, like the TCP jack.
• Using Python stdlib modules instead of PyCrypto is fine, as long as availability is not a problem (so this is a case where that would be okay).
• My vote would be to make OpenSSL a dependency on Windows. NotImplementedError is fine, we don't really have a standard yet for dealing with missing dependencies, and we can go back and standardize later if we decide how we want to do it.

[MoritzS]

I'll wait for #66 to be implemented until I finish working on this because that will introduce some heavy changes to Jacks and a total remake will be necessary.