[WIP] Support ALPN on Security Framework #100
Conversation
This change exposes security-framework's ALPN methods through native-tls. security-framework 0.2.1 doesn't have ALPN methods yet. So the build wouldn't succeed now.
|
This branch is still work-in-progress. I'm unsure how to provide the feature on platforms that don't support ALPN (e.g. older OS X versions) |
There was a problem hiding this comment.
My current thinking on how we would deal with ALPN on unsupported platforms (e.g. OSX 10.12, OpenSSL 1.0.1, Windows Vista) is that the APIs would always be present, but ALPN would just not run when it isn't supported.
For Security.framework we'll probably have to implement this by not actually using the security-framework but by instead using dlsym to dynamically load the symbols at runtime if present.
| @@ -628,6 +641,11 @@ impl<S: io::Read + io::Write> TlsStream<S> { | |||
| Ok(self.0.tls_server_end_point()?) | |||
| } | |||
|
|
|||
| /// Returns the negotiated protocols | |||
| pub fn negotiated_protocols(&self) -> Result<Vec<String>> { | |||
There was a problem hiding this comment.
ALPN only allows a single protocol to be negotiated, so this should return a Result<Option<String>>.
|
Would it make sense to return Regarding |
|
Returning an error is a possibility, yeah. SSLContext is already exposed through the TCFType impl. |
|
Well, while SSLContext is available as a type, getting that from secure_transport::SslStream may need some changes in native-tls. Wouldn't it be? |
|
It's directly accessible from here: https://github.com/sfackler/rust-native-tls/blob/master/src/imp/security_framework.rs#L355 |
|
Thanks. I'm trying to implement the suggested dlopen-based method on native-tls side. SSLSetALPNProtocols must be called before/during handshake(), against the context. However I think security-framework currently doesn't provide hook points to do that. |
|
We could skip the ClientBuilder and manage the SSLContext directly but there's quite a bit of logic there... |
|
Yep. Then again, wouldn't be easier to have dlopen in security-framework? security-framework is currently just a simple one-to-one wrapper for Security.framework. Having dlopen would complicate the crate though. |
|
I've opened a new pull request on rust-security-framework, that replaces ALPN-related methods with dlopen-based implementation. |
|
Let me close this PR for a moment, since I haven't been working on that for more than a month. @seanmonstar did similar work for OpenSSL, but we need to make some progress on steffengy/schannel-rs#49 first to have ALPN on rust-native-tls. |
This change exposes security-framework's ALPN methods through
native-tls.
security-framework 0.2.1 doesn't have ALPN methods yet.
So the build wouldn't succeed now.