Git Repositories

Age	Commit message (Collapse)	Author
2012-02-14	Add parsing of XMPP and SRV subjectAltNames to JavaCertificate	Nick Hudson
	The JavaCertificate class functionality copies that found in Swiften's OpenSSLCertificate class. One of the things that the class needs to do is make available lists of SRV and XMPP names which are contained in the certificate's subjectAltName extensions. However, unlike OpenSSL, the standard Java classes don't provide support for parsing the different types of subjectAltNames that we want - what Java provides is a method to return the DER encoded values, and so this change adds functions to the JavaCertificate class to parse these values to extract Strings corresponding to either XMPP or SRV subjectAltNames. Also addressed a couple of comments from a previous patch. Test-information: Tested with certificate that has subjectAltNames for - Service Name _xmpp-client.funky.isode.net - Service Name _xmpp-server.funky.isode.net - XMPP address funky.isode.net - DNS Name funky.isode.net And verified that all of these are parsed and made available with the relevant methods. Verified that a certificate which does NOT contain any of these subjectAltNames is parsed with no errors (and the code reports no matching subjectAltNames) Signed-off-by: Nick Hudson <nick.hudson@isode.com>
2012-02-13	Initial implementation of TLS support	Nick Hudson
	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.