diff options
author | Nick Hudson <nick.hudson@isode.com> | 2013-01-24 12:16:40 (GMT) |
---|---|---|
committer | Nick Hudson <nick.hudson@isode.com> | 2013-01-29 11:41:19 (GMT) |
commit | ebef58ff180acc9d760ea0137216ef6b4f16a9b6 (patch) | |
tree | 658b2d513cd993d23e5d56ff0b3f9ae6c0132fcb /README | |
parent | 37730a9bfe2e31ae0d7adc9cd7247d1e15d0f6da (diff) | |
download | stroke-ebef58ff180acc9d760ea0137216ef6b4f16a9b6.zip stroke-ebef58ff180acc9d760ea0137216ef6b4f16a9b6.tar.bz2 |
Changes to Stroke to make it more amenable to porting to other platforms
Two things
- the implementation of JavaTrustManager was attempting to instantiate a
TrustManagerFactory with a hard-coded name of "PKIX", which doesn't
work on Android. So instead of that, we ask for the
TrustManagerFactory's default algorithm - which for the standard JRE
still appears to be "PKIX", but which for Android may be something
else.
- the "hack" which had been in place to force the SSLEngine to
perform a TLS handshake has been removed.
Calling "SSLEngine.beginHandshake()" is not guaranteed to make the
SSLEngine perform the TLS handshake, which it typically only does when
it is told to wrap some data from the client. The earlier version of
JSSEContext provoked this by asking it to send a "<" character, and
then removing the leading "<" from whatever Stroke happened to send next.
It turns out that you can force the handshake to start by telling the
SSLEngine to wrap 0 bytes of data from the client, and so this change
removes the hack, and instead calls "wrapAndSendData()" with an empty
buffer as soon as the SSLEngine has been created.
Test-information:
Ran XMPP client that uses TLS and verified that everything still works
as expected.
Change-Id: Ie08d76bd2f5a743320a59bad62a09c1f215c48d6
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions