[Jython-dev] Client side SSL api.

[Alan K. <jyt...@xh...>]

Dear all,

A query about client-side SSL support came up on jython-users last week, 
whereby someone was expecting a cpython code sample using SSL to work on 
jython.

In fact, cpython-compatible ssl support is quite straightforward, so I 
went ahead and wrote it. And plan to submit it to jython.

However, I wanted to finalise an API before doing so, and wanted to 
discuss this with ye.

Unfortunately, the cpython API is extremely basic. You can read the 
description here

http://docs.python.org/lib/module-socket.html
http://docs.python.org/lib/ssl-objects.html

Areas of note include

1. cpython ssl sockets don't do validation. Which is less than ideal.
  - But java validates all certificates by default. So any jython 
implementation would actually have to disable certificate checking to be 
fully cpython compatible. Which makes little sense.

2. The "ssl" callable in the socket module takes two optional 
parameters: "keyfile is the name of a PEM formatted file that contains 
your private key. certfile is a PEM formatted certificate chain file."
  - I thought that passwords were required to decode the contents of a 
PEM file? But there is no cpython API parameter to supply passwords: so 
does accepting these parameters without passwords make sense?

3. Each SSLObject has two methods to access certificate information. 
There is a lot to say here.
  - The methods only provide access to metadata about the server 
certificate, but not the chain of certificates that actually verified 
trust in this connection.
  - The "ASN.1" format that is returned is not parseable, and 
potentially exploitable. See here

https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470

  - There is no mechanism for retrieving the expiry date for a certificate
  - There is no mechanism for retrieving encryption algorithm metadata 
about the SSL session, e.g. algorithm, keysize, etc.
  - Etc.

So I need to decide which of these problems to address, and which to 
punt on, in the interests of getting something running out there. 
Decision I've already made which I'm happy with are

1. I am not going to expose the entire wide range of java functionality 
available. That would take weeks and weeks of researching, coding and 
testing, which I don't have time for.

If people have serious crypto needs for SSL sockets, then they can 
easily access the full range of java functionality available: it's well 
documented, thoroughly tested, regularly audited for security problems, 
etc, etc. What's more, there is a wide range of alternate options 
available, such as Legion of the Bouncy Castle (www.bouncycastle.org), etc.

2. I want to enable simple use cases, such as being able to connect to 
an SSL socket testing, automation, etc, in such a way that cpython code 
samples that people find on the net will work seamlessly on jython 
without modification.

3. I don't want to implement a key store management infrastructure, a 
certificate management infrastructure, etc. There's plenty of tools in 
the java tookit for that.

4. If someone else is really interested in implementing a cpython 
compatible SSL API for jython, then I encourage them to do so, and 
recommend following a tried-and-tested API, such as m2Crypto, etc.

So, if anyone has the time, I'd like to hear opinions on these issues

1. I plan to break compatibility with cpython, leave certification 
validation in place on jython, and raise an exception if validation 
fails. What should that exception be? A subclass of socket.ssl_error? Or 
from some independent "Authorisation" exception hierarchy?

2. I plan to extend the "ssl" call to take an optional keyword parameter 
to control certificate validation: it would default to ON, and would 
have to be turned explicitly OFF to mimic cpython.

3. Is it worth leaving the "keyfile" and "certfile" arguments in place? 
Can they be used without passwords?

4. I would like to provide basic access to the certificate chain after 
validation. Would returning an array of certificate objects be 
sufficient? Specifically, the list of certificate objects made available 
from the SSLSession.getPeerCertificates() method.

http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSession.html#getPeerCertificates()

5. The only information made available about certificates in cpython is 
this flawed "ASN.1" string, which is not parseable and may be insecure. 
Which option is preferable?

   - Provide access to the cert data by returning a properly formatted 
and parseable string. It is relatively straightforward to generate an 
RFC-2253 compatible representation, using 
java.security.X500Principal.getName("RFC2253")

http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String)

   - Provide access to the certs themselves by simply returning the 
java.security.Certificate objects? Which would require the users to read 
the java documentation for same.

   - Wrap those objects in some way, to provide a "jythonic" API?

I'd be glad to hear thoughts or suggestions on this.

Regards,

Alan.