#38 SSL pinning draft implemetation

[vvsevolodovich]

Let's review the general approach and discuss the details after.

[TakahikoKawasaki]

Thank you. I'll start reading your code.

BTW, however, if the license of your source files is GPL, nv-websocket-client cannot accept them.

[vvsevolodovich]

Well, I see the issue. What about I will rewrite the files in order not to be limited with GPL?

[twogood]

Code is copied from https://github.com/moxie0/AndroidPinning - it can't just be "rewritten".

[vvsevolodovich]

I know that, but nobody can restrict me from creating my own code using ideas from that library?

[TakahikoKawasaki]

I'm sorry for having not responded so long because I'm recently really busy...

I think that RFC 7469 (Public Key Pinning Extension for HTTP) should be read to judge whether an implementation is a natural result from the specification or a copy from another implementation. I should read the specification...

[matt-thinair]

Any update here? We're using this (very elegant!) websockets library and need cert pinning

[TakahikoKawasaki]

@matt-thinair Sorry, no update. Thank you for reminding me of this.

[bri3d]

In the wild, "certificate pinning" generally refers simply to "verifying that server's certificate and/or public key signature match a fixed set of certs or public key signatures encoded into the application."

Neither the code in this PR nor most client developers implement RFC 7469 - that's a separate specification which documents a mechanism for HTTP servers to specify that a client should "remember" Subject Public Key Info via HTTP header.

@matt-thinair You can implement the typical case of "cert pinning" using the existing implementation of the library, without needing additional modifications to the library code. Use setSSLContext on the Factory to pass in a Context you've set up using your own custom TrustManager , using the method documented in https://developer.android.com/training/articles/security-ssl.html#UnknownCa to add only your own certificates to the TrustManager.