Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion #1

Open
samoconnor opened this issue Mar 6, 2018 · 3 comments
Open

Discussion #1

samoconnor opened this issue Mar 6, 2018 · 3 comments

Comments

@samoconnor
Copy link
Collaborator

Moving discussion over from: JuliaLang/MbedTLS.jl#125 (comment)

Re: ... a package that integrates with an OS's native TLS toolkit ...

I don't know if I'll have time to work on this any time soon, but I though it was worth making some notes given that it's been on my mind. I've sketched out some ideas here:
https://github.com/samoconnor/TLSClient.jl/blob/master/README.md

JuliaLang/MbedTLS.jl#125 (comment) :

I'll just say that for historical context, there have been somewhere between 2-5 distinct attempts at writing OpenSSL bindings for Julia in the past. I'm not going to try to comprehensively list them, but you can look around and find them - to my knowledge none have seen any development at any time within the last year or two, or longer. There was GnuTLS.jl which was actively used for a while (mostly for license compatibility reasons) but it had its set of problems and fell out of favor rapidly as soon as Jon wrote this package and got it up and functional.

When you work with OpenSSL, you also need to worry about how its API has changed over time, and the widely varying versions out there in the wild on different ages of Linux distro. The forks like LibreSSL and BoringSSL are also viable options. I don't know whether anyone has tried to write Julia bindings for WinHTTP or SecureTransport.

https://blog.regehr.org/archives/1261 is also an interesting anecdote, but from a few years ago.

@samoconnor
Copy link
Collaborator Author

widely varying versions out there in the wild on different ages of Linux distro.

That's a good point.

I'm thinking that it might be best to think about targeting os platforms rather than libraries.
e.g. we could target:

  • macOS 10.12 +
  • iOS 11 +
  • Android 8 +
  • Ubuntu 16 LTS +
  • Centos 7 +
  • Amazon Linux 2017.09 +
  • Windows 10 +

(and anything that's not on the list uses a fallback, e.g. MbedTLS.jl + uvlib TCPSocket).

If half of those share a common OpenSSL version, that's a happy coincidence.

If we assume that backend implementations consist of just a dynamic library that implements tls_client.h. Then we can keep lib_jl_tls_centos_7.so around forever via BinaryProvider and it should keep working on Centos 7 even if everyone else has moved on to Centos 8, 9, 10.

@samoconnor
Copy link
Collaborator Author

Re: https://blog.regehr.org/archives/1261
Interesting that it says that the formal verification of MbedTLS (nee PolarSSL) "excludes some parts such as X.509". That in effect means as far as I understand, that they did not verify the code that tells the client that it is ok to trust the server. However, it's nice to know that considerable effort was put into verifying parts of PolarSSL.

With s2n you have to set a env var S2N_ENABLE_CLIENT_MODE because Amazon is not 100% happy with their X.509 code: https://github.com/awslabs/s2n/blob/master/docs/USAGE-GUIDE.md#client-mode

@samoconnor
Copy link
Collaborator Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant