|
By default, when a TLS connection is established, the SSLContext will
enable all available ciphersuites. This may not be appropriate in
situations where export restrictions apply and higher grade
ciphersuites are prohibitied.
This change allows a caller to configure a restricted set of
ciphersuites to be used when establishing TLS connections.
Callers use the JSSEContextFactory.setRestrictedCipherSuites() method
to configure a list of ciphersuites. Any ciphersuites which are not
included in the list will be excluded in subsequent TLS connections.
If the JSSEContextFactory.setRestrictedCipherSuites() is never called,
or called with a null parameter, then no restriction will apply.
Test-information:
Validated that by calling the new method to restrict the available
ciphers, TLS connections initiated by Stroke only propose ciphersuites
in the restricted list, and connections fail when the server fails to
find an acceptable cipher.
Change-Id: Id0b4b19553a6f386cda27a71f0172410d899218e
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
The nascent support for TLS is now enabled by the uncommenting of a
line in "PlatformTLSFactories" which means that Stroke will now try
and negotiate TLS when connecting to a server that offers it.
Note that further changes will be required to allow configuring of
client certificate and trust anchors.
In performing testing, a couple of problems were found and have been
fixed by this patch:
- The "hack" field inside JSSEContext, which keeps track of whether
the fake "<" character used to provoke an SSL handshake has been
sent was mistakenly declared static, which meant that if you tried
using TLS on more than one session, things didn't work
properly. This has been fixed.
- The buffer used for incoming encrypted data for the SSLEngine in
JSSEContext is created with a size that matches "the largest
SSL/TLS packet that is expected". But it turns out not to be big
enough to cope with all the data that the JavaConnection class
might provide when calling "handleDataRead()".
So the "handleDataFromNetwork" method is changed to break this data
into chunks that will fit into the buffer. The same technique is
used in "handleDataFromApplication" for cases where the application
provides more data than is will fit in a buffer.
- All of the "ByteBuffer" values are initialised with a size as
recommended by the Sun documentation, although in some cases it
appears that these sizes may not be enough (you are cautioned to be
able to cope with the buffers overflowing)
So all of the ByteBuffers are able to grow, up to a maximum of ten times
there initial size, using the "enlargeBuffer()" method.
Note that in most cases, I could only provoke buffer overflows in
my tests by deliberately starting off with buffers that are too
small.
- When testing with JRE7, it became apparent that the behaviour of
the SSLEngine and SSLContext classes had changed, which initially
resulted in "hangs" being seen as the SSLEngine did not appear to
decrypt data being fed to it until subsequent SSL messages arrived
and appeared and to prod it into life.
This behaviour is influenced by the version of TLS handshake being
used, which made it awkward to debug, since some versions of TLS handshake
worked fine for JRE6 but not JRE7 and vice versa; also different servers
would negotiate different with different handshakes.
Eventually this turned out to be a pre-existing bug in the initial
JSSEContext implementation: specifically the "unwrapPendingData()"
method had been assuming that a call to SSLEngine.unwrap() would
consume all pending data (which is the case for in all scenarios
using JRE6, and is often, but not always, the case for JRE7).
So the fix for the problem is to loop inside "unwrapPendingData" until
calls to unwrap() don't consume any more data.
- I also added some logging to JSSEContext - warnings when an error
is emitted, and a "fine" message when buffer sizes have to be
increased.
- Also, double-slash comments are replaced by /*..*/ style in JSSEContext
Test-information:
Before this patch, TLS wasn't starting. Now it does.
Before the bug fixes, concurrent TLS connections to more than one
server resulted in "corruption" of the streams, with errors being
generated relating to XML parsing errors at both client/server.
Before the bug fixes, large messages from the server (~36K) would
cause "BufferOverflow" exceptions and connections to drop.
After the bug fixes, these problems are no longer seen.
Before the bug fixes, TLS sessions would sometimes (depending on what
version of TLS the server negotiated, and what version of JRE you were
using) appear to "hang". Now they don't.
I also tested creating artificially small buffers to make sure that
the various "buffer overflow" situations are handled properly. I
wasn't able to provoke all of these problems in a real
configuration, so I suspect that the "enlargeBuffer" stuff may not
actually get used much, but it has been tested.
All tested with JRE6 and JRE7
|
|
Note that TLS won't be enabled with this patch unless you uncomment the
change in PlatformTLSFactories. With that comment removed, then a new
CoreClient session will attempt to negotiate TLS if the server supports
it.
Further changes are required to support this properly, as there
appears not to be comprehensive support in the CoreClient class for
dealing with situations when the server's certificate is not acceptable.
There's also no support yet for setting up client certificates.
Further changes will also be needed (see below) to support full
parsing of subjectAltNames from server certificates.
Significant changes are as follows
- TLSProceed - FIXME comments removed
- JavaConnection - changed so that it reads bytes from the socket's
InputStream, rather than reading chars and then constructing a
String out of them from which a byte array is then extracted.
While this seemed to work for non-binary data (e.g. non-encrypted
XMPP sessions), it breaks when you start sending binary (i.e. TLS)
data.
- JavaTLSConnectionFactory - implemented
- PlatformTLSFactories - By having this return a JSSEContextFactory, then
this will cause the client to try TLS if possible. But because other
changes are needed to make this work properly, the current code still
returns null.
- JSSEContext - new class which uses an SSLEngine to handle TLS handshake
and subsequent encryption/decryption. This is the main substance of
the SSL implementation
Note the "hack" in here to cope with SSLEngine requiring that some data
be sent from the application before it will do a TLS handshake
- JSSEContextFactory - just creates JSSEContexts
- JavaCertificate - this wraps an X509Certificate and does *some* of the
parsing of a certificate to look for stuff that is expected when
verifying an XMPP server certificate (RFC 6120 and RFC 6125). Note that
the JDK classes for parsing certificates don't provide an easy way
to decode "OTHER" subjectAltNames, and so this implementation does
not find XMPP or SRV subjectaltnames from the server certificate. This
will need extra work.
- JavaTrustManager - obtains the server certificate from the TLS handshake
and verifies it. Currently the only verification done is to check that
it's in date. More work will be needed to perform proper validation
- Where necessary, Remko's copyright comments were changed from GNU to
"All rights reserved". Isode copyright notices updated to "2012"
Test-information:
Set up XMPP server with its own certificate, and checked that TLS gets
negotiated and starts OK (provided the server cert contains e.g. a DNS
subjectAltName matching its own name). Subsequent operation appears
to be as expected.
|
Swift