[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=all ]
Julius Davies updated HTTPCLIENT-614:
-------------------------------------
Attachment: ssl.patch
This patch introduces a pluggable HostnameVerifer implementation, including
JUnit tests. I also threw in two other things:
#1. Use HttpsURLConnection.getDefaultSSLSocketFactory().
------------------------------------
the no-arg SSLSocketFactory() constructor now uses:
HttpsURLConnection.getDefaultSSLSocketFactory();
This way the client certs in the browser will also be available when using Java
Webstart, and brings our "https" behaviour even closer to java.net.URL's.
#2. JUnits for SSLSocketFactory
------------------------------------
JUnit dependency on commons-codec. This is so I can decode a base64 RSA
private key I stored inside "CertificatesToPlayWith". Probably I should
unravel that and just store the BigIntegers directly, and get rid of the
commons-codec dependency.
This RSA private key is important so that we can build our own JKS, store it
using a temp file, set the "javax.net.ssl.keystore" system property, and become
our own SSLServer in a reliable and repeatable way. We also set the
"javax.net.ssl.truststore" system property to point to the same temp file so
that we can make sure HttpsURLConnection.getDefaultSSLSocketFactory() isn't
stabbing us in the back!
All JUnit tests are passing on Linux with:
Sun 1.4.2
Sun 5.0
Sun 6.0-rc
IBM 1.4.2
IBM 5.0
> allow different strategies when checking CN of x509 cert
> --------------------------------------------------------
>
> Key: HTTPCLIENT-614
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-614
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpConn
> Affects Versions: Nightly Builds
> Reporter: Julius Davies
> Fix For: 4.0 Alpha 1
>
> Attachments: ssl.patch
>
>
> We're now doing a decent job for checking the CN of the x509 cert with https:
> http://issues.apache.org/jira/browse/HTTPCLIENT-613
> I think the patch for HTTPCLIENT-613 should cover 99.9% of the users out
> there. But there are some more esoteric possibilities, so I think Oleg is
> right. We need to let the user change the strategy, or provide their own
> strategy if they want to.
> Some additional things to think about:
> - http://wiki.cacert.org/wiki/VhostTaskForce !!! CN is depreciated?!?! (I
> am not able to find a popular website on HTTPS that isn't using CN!)
> - [*.example.com] matches subdomains [a.b.example.com] on Firefox, but not
> IE6. The patch for HTTPCLIENT-613 allows subdomains.
> - Should we support multiple CN's in the subject?
> - Should we support "subjectAltName=DNS:www.example.com" ? Should we support
> lots of them in a single cert?
> - Should we support a mix of CN and subjectAltName?
> If we do create some alternate strategies for people to try, I'd probably
> lean towards something like this:
> X509NameCheckingStrategy.SUN_JAVA_6 (default)
> X509NameCheckingStrategy.FIREFOX2
> X509NameCheckingStrategy.IE7
> X509NameCheckingStrategy.FIRST_CN_AND_NO_WILDCARDS (aka "STRICT")
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
