You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Julius Davies (JIRA)" <ji...@apache.org> on 2006/12/08 16:45:21 UTC
[jira] Created: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
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: HttpClient
Affects Versions: Nightly Builds
Reporter: Julius Davies
Priority: Minor
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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=comments#action_12458559 ]
Oleg Kalnichevski commented on HTTPCLIENT-614:
----------------------------------------------
Julius,
I'll review and commit the patch later tonight or tomorrow in the evening
Oleg
> 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-better.patch, ssl-even-better.patch, 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=comments#action_12456909 ]
Julius Davies commented on HTTPCLIENT-614:
------------------------------------------
Hi, Odi,
I believe "host.endsWith( cn.substring( 1 ) )" mimics Firefox's behaviour (but without support for "CN + SubjAltNames").
This wiki entry has an interesting catalog of browser behaviour with wildcards:
http://wiki.cacert.org/wiki/WildcardCertificates
- IE6 doesn't allow subdomains (so follows the RFC). *.apache.org does not match "a.b.apache.org".
- Firefox/Mozilla allows subdomains (breaks RFC). *.apache.org DOES MATCH "a.b.apache.org"!
- New versions of Konqueror (so Safari too?) allows subdomains (breaks RFC).
- Opera 9.0 allows subdomains (breaks RFC).
I think I'll do some experimentation on my own and test some additional clients. I'll add my findings to cacert's very handy wiki! Curious about the following (but I'm lazy so I'm just going to stick to Linux and maybe a little dabbling on Windows):
- wget
- curl
- java.net.URL on the following:
1. Sun Java 1.3.1 + JSSE
2. Sun Java 1.4.2
3. Sun Java 5.0
4. Sun Java 6.0
5. IBM Java 1.4.2
6. IBM Java 5.0
7. JRockit Java 1.4.2
8. JRockit Java 5.0
I think if our default behaviour mimics Sun Java 6, that's good enough.
> 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
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=all ]
Julius Davies updated HTTPCLIENT-614:
-------------------------------------
Attachment: ssl-better.patch
- this patch is better: removed dependency on commons-codec
- no longer accidentally including setTimeout() in DefaultHttpHostConnection.java (required for javac, though!)
> 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-better.patch, 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=comments#action_12456895 ]
Ortwin Glück commented on HTTPCLIENT-614:
-----------------------------------------
Good point, Julius. Personally I have no experience with SSL on vhosts. But looking at the references document it looks like we should support the "CN+SubjAltNames" and "SubjectAltName" variants.
May I mention that the * solution in 613 is wrong:
if ( wildcard ) match = host.endsWith( cn.substring( 1 ) );
would result in bar.foo.a.com matching *.a.com
but RFC says:
E.g., *.a.com matches foo.a.com but not bar.foo.a.com.
Making a mistake here opens spoofing possibilities!
> 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: HttpClient
> Affects Versions: Nightly Builds
> Reporter: Julius Davies
> Priority: Minor
>
> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Resolved: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-614.
------------------------------------------
Resolution: Fixed
* Moved all concrete HostnameVerifier impls from the interface declaration to separate public classes
* Renamed DEFAULT HostnameVerifier to BROWSER_COMPATIBLE (still used per default, but we may want to use STRICT instead in the future)
Closing as FIXED. Many thanks for this contribution, Julius
Oleg
> allow different strategies when checking CN of x509 cert
> --------------------------------------------------------
>
> Key: HTTPCLIENT-614
> URL: https://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-better.patch, ssl-even-better.patch, 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=all ]
Julius Davies updated HTTPCLIENT-614:
-------------------------------------
Attachment: ssl-even-better.patch
- No more japanese characters directly in the source files. Using "\u82b1\u5b50" instead. These japanese hostname tests are probably silly (will never occur in real life thanks to ""xn--i8s592g.co.jp" puny encoding. But they're fun. :-)
Oleg, can we commit this version, and then look into a factory approach?
> 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-better.patch, ssl-even-better.patch, 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
[ 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Julius Davies (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=comments#action_12457447 ]
Julius Davies commented on HTTPCLIENT-614:
------------------------------------------
Trying out a pluggable implementation.
If anyone is interested in seeing where I'm currently at:
http://juliusdavies.ca/httpclient/
Of note:
New interface:
o.a.http.conn.ssl.HostnameVerifier
It actually extends the javax.net.ssl one (http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/HostnameVerifier.html). But I don't expect our SSLSocketFactory to use that API. I'm just including that as a comforting "things seem familiar" door-knob/hand-rail.
Of note, I'm actually sticking the implementation directly inside this interface as anonymous-inner-classes. Defining the following:
HostnameVerifier.DEFAULT (mimics curl and firefox)
HostnameVerifier.STRICT (mimics java.net.URL, and very close to IE6)
HostnameVerifier.ALLOW_ALL (turns off hostname verification)
IIRC, anonymous inner-classes only showed up in Java 1.3.x so this would be inappropriate for Httpclient 3.x (which supports Java 1.2.x).
Now I'm just working on unit tests before I create the patch....
> 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
>
>
> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=comments#action_12457673 ]
Oleg Kalnichevski commented on HTTPCLIENT-614:
----------------------------------------------
Julius,
Would it be possible to get rid of dependency on commons-codec, especially if it is only needed to run test cases?
I personally would prefer to move all HostnameVerifier impls to o.a.http.conn.impl package. HostnameVerifier.DEFAULT and friends should probably be better off moved to an object factory of a sort.
I'll review the patch more thoroughly tomorrow and check it in to the SVN trunk
Oleg
> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=comments#action_12458604 ]
Oleg Kalnichevski commented on HTTPCLIENT-614:
----------------------------------------------
Patch checked in. Many thanks, Julius
Oleg
> 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-better.patch, ssl-even-better.patch, 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=all ]
Oleg Kalnichevski updated HTTPCLIENT-614:
-----------------------------------------
Priority: Major (was: Minor)
Julius,
We have been through a similar process with HTTP cookie policies. Pluggable validators is the way to go. Anyone who needs a specific way of validating host names is very welcome to build his/her own. We should provide two policies (validators) out of the box: the RFC compliant (strict) and the browser compatible (lapse). No need to mimic every single bloody browser out there.
Oleg
> 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
>
>
> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-614) allow different strategies when
checking CN of x509 cert
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-614?page=all ]
Oleg Kalnichevski updated HTTPCLIENT-614:
-----------------------------------------
Component/s: HttpConn
(was: HttpClient)
Fix Version/s: 4.0 Alpha 1
> 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
> Priority: Minor
> Fix For: 4.0 Alpha 1
>
>
> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org