You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2014/08/21 15:26:41 UTC
CVE-2014-3577 postmortem
Dirk-Willem et al
I have pretty much completely rewritten every bit of code related to
hostname verification in SVN trunk.
https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
I would truly appreciate someone doing a peer review of the changes
and / or giving me feedback with regards to further improvements.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: CVE-2014-3577 postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>
> > I have pretty much completely rewritten every bit of code related to
> > hostname verification in SVN trunk.
> >
> > https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
> >
> > I would truly appreciate someone doing a peer review of the changes
> > and / or giving me feedback with regards to further improvements.
>
> Looks good. Couple of thoughts
>
Continued.
> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>
> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
>
Would you recommend the file be retrieved at runtime dynamically or
shipped with the application as a static resource (and updated with
every public release)?
> about revil regexes slipping in (e.g. ReDoS); and then causing some sort of exhaustion*.
>
> - countDots function
>
> Prolly no longer used.
>
Not need and should have never been a part of public APIs in the first
place but we need to keep it for full backward compatibility.
Thank you once again.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: CVE-2014-3577 postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2014-08-25 at 12:53 +0200, Dirk-Willem van Gulik wrote:
> > Op 22 aug. 2014, om 18:31 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
...
> >> Now *all* that is allowed are ‚*’ — and as far as I know - only in string (and not IPv4/IPv6) based entries.
> >>
> >> So perhaps it is an option to compare things from the TLD down with a very very simple loop.
> >>
> >> if (starts with a star) then
> >> @a = array of FQDN split on ‚.'
> >> @b = array of FQDN split on ‚.’
> >>
> >> if not right lenghts - bail
> >> working from the topmost side working to last but one
> >> bail if not the same.
> >> check if we have left just one entry on a and a wildcard on b.
> >>
> >> i.e. avoid wildcards completely.
> >
> > Please correct me if I am wrong but after rereading relevant RFCs I was
> > under impression that complex wild card expressions in subjectAltName
> > like
> >
> > a*b*c*d.mydomain.com <http://d.mydomain.com/>
> >
> > were perfectly legal. This was the primary reason why I felt the use of
> > regex matching was beneficial. Should we revert to supporting simple
> > '*', 'blah*' expressions only?
>
> Not sure - doing more research after reading the RFC’s - they are much more strict about i18n domains; and I am not sure if I understand all the implications.
>
> Dw.
Hi Dirk-Willem
After having re-read RFC 2818 section 3.1 (Server Identity) I realized I
was most likely wrong
"...Names may contain the wildcard character * which is considered to
match any single domain name component or component fragment..."
Based on this statement I presume only singular wildcard is legal.
I re-wrote hostname verification logic one more time completely doing
away with regex matching per your recommendation in favor of simple
suffix / prefix matching based on the above assumption. Also, the
default HostnameVerifier implementation can now make use of public
suffix list to ensure that the server identity obtained from the
certificate is outside of the public domain space.
Please let us know what you think.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: CVE-2014-3577 postmortem
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> Op 22 aug. 2014, om 18:31 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>
> On Fri, 2014-08-22 at 12:47 +0200, Dirk-Willem van Gulik wrote:
>>>> Found that some of below are indeed able to hang the regex stack (e.g. # 2). However the more elaborate regex-es are blocked by:
>>>>
>>>> private final static Pattern WILDCARD_PATTERN = Pattern.compile( "^[a-z0-9\\-\\*]+(\\.[a-z0-9\\-]+){2,}$", Pattern.CASE_INSENSITIVE);
>>>> ..
>>>> WILDCARD_PATTERN.matcher(identity).matches()
>>>>
>>>> which we apply to the subjectAltName, CN, etc. So that is not too bad then - assuming that that regep does not let them through. Which is likely - as the only dangerous thing I see in there is a *.
>>>>
>>>
>>> Thank you so much for your feedback. What I could do is validate both
>>> the identity and the subjectAltName pattern by making sure they consist
>>> of characters legal for domain names (alphanumeric, dash and asterisk in
>>> case of subjectAltName) prior to doing regexp matching with them.
>>
>> Right - but I am wondering if that means we end up in a rear guard battle. As we then find IPv6 addresses containing ‚:’ and god knows what new TLDs may do 5+ years hence.
>>
>
> 5+ is pretty much my retirement target ;-)
>
> Seriously, though, I would worry about UTF8 issues only once start
> getting angry complaints from users. Right now I would rather be too
> restrictive than too liberal.
>
>> Now *all* that is allowed are ‚*’ — and as far as I know - only in string (and not IPv4/IPv6) based entries.
>>
>> So perhaps it is an option to compare things from the TLD down with a very very simple loop.
>>
>> if (starts with a star) then
>> @a = array of FQDN split on ‚.'
>> @b = array of FQDN split on ‚.’
>>
>> if not right lenghts - bail
>> working from the topmost side working to last but one
>> bail if not the same.
>> check if we have left just one entry on a and a wildcard on b.
>>
>> i.e. avoid wildcards completely.
>
> Please correct me if I am wrong but after rereading relevant RFCs I was
> under impression that complex wild card expressions in subjectAltName
> like
>
> a*b*c*d.mydomain.com <http://d.mydomain.com/>
>
> were perfectly legal. This was the primary reason why I felt the use of
> regex matching was beneficial. Should we revert to supporting simple
> '*', 'blah*' expressions only?
Not sure - doing more research after reading the RFC’s - they are much more strict about i18n domains; and I am not sure if I understand all the implications.
Dw.
Re: CVE-2014-3577 postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2014-08-22 at 12:47 +0200, Dirk-Willem van Gulik wrote:
> >> Found that some of below are indeed able to hang the regex stack (e.g. # 2). However the more elaborate regex-es are blocked by:
> >>
> >> private final static Pattern WILDCARD_PATTERN = Pattern.compile( "^[a-z0-9\\-\\*]+(\\.[a-z0-9\\-]+){2,}$", Pattern.CASE_INSENSITIVE);
> >> ..
> >> WILDCARD_PATTERN.matcher(identity).matches()
> >>
> >> which we apply to the subjectAltName, CN, etc. So that is not too bad then - assuming that that regep does not let them through. Which is likely - as the only dangerous thing I see in there is a *.
> >>
> >
> > Thank you so much for your feedback. What I could do is validate both
> > the identity and the subjectAltName pattern by making sure they consist
> > of characters legal for domain names (alphanumeric, dash and asterisk in
> > case of subjectAltName) prior to doing regexp matching with them.
>
> Right - but I am wondering if that means we end up in a rear guard battle. As we then find IPv6 addresses containing ‚:’ and god knows what new TLDs may do 5+ years hence.
>
5+ is pretty much my retirement target ;-)
Seriously, though, I would worry about UTF8 issues only once start
getting angry complaints from users. Right now I would rather be too
restrictive than too liberal.
> Now *all* that is allowed are ‚*’ — and as far as I know - only in string (and not IPv4/IPv6) based entries.
>
> So perhaps it is an option to compare things from the TLD down with a very very simple loop.
>
> if (starts with a star) then
> @a = array of FQDN split on ‚.'
> @b = array of FQDN split on ‚.’
>
> if not right lenghts - bail
> working from the topmost side working to last but one
> bail if not the same.
> check if we have left just one entry on a and a wildcard on b.
>
> i.e. avoid wildcards completely.
Please correct me if I am wrong but after rereading relevant RFCs I was
under impression that complex wild card expressions in subjectAltName
like
a*b*c*d.mydomain.com
were perfectly legal. This was the primary reason why I felt the use of
regex matching was beneficial. Should we revert to supporting simple
'*', 'blah*' expressions only?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: CVE-2014-3577 postmortem
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
>> Found that some of below are indeed able to hang the regex stack (e.g. # 2). However the more elaborate regex-es are blocked by:
>>
>> private final static Pattern WILDCARD_PATTERN = Pattern.compile( "^[a-z0-9\\-\\*]+(\\.[a-z0-9\\-]+){2,}$", Pattern.CASE_INSENSITIVE);
>> ..
>> WILDCARD_PATTERN.matcher(identity).matches()
>>
>> which we apply to the subjectAltName, CN, etc. So that is not too bad then - assuming that that regep does not let them through. Which is likely - as the only dangerous thing I see in there is a *.
>>
>
> Thank you so much for your feedback. What I could do is validate both
> the identity and the subjectAltName pattern by making sure they consist
> of characters legal for domain names (alphanumeric, dash and asterisk in
> case of subjectAltName) prior to doing regexp matching with them.
Right - but I am wondering if that means we end up in a rear guard battle. As we then find IPv6 addresses containing ‚:’ and god knows what new TLDs may do 5+ years hence.
Now *all* that is allowed are ‚*’ — and as far as I know - only in string (and not IPv4/IPv6) based entries.
So perhaps it is an option to compare things from the TLD down with a very very simple loop.
if (starts with a star) then
@a = array of FQDN split on ‚.'
@b = array of FQDN split on ‚.’
if not right lenghts - bail
working from the topmost side working to last but one
bail if not the same.
check if we have left just one entry on a and a wildcard on b.
i.e. avoid wildcards completely.
> Obviously - as we get into UTF8 internationalized domain names - we may accidentally break that protection at some point.
>
> Would not internationalized domain names be Punycode encoded instead?
Yes - but I am worried about the easy to make mistakes; and the lack of normalization* some people my accidentally not apply. The CA’s do not have a good track record.
But none of this is very urgent/key - just more a robustness thing.
Dw.
*: e.g. things like invisible unicode chars to do a ‚backspace’ or visually wipe text.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: CVE-2014-3577 postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-08-21 at 18:36 +0200, Dirk-Willem van Gulik wrote:
> Op 21 aug. 2014, om 17:50 heeft Dirk-Willem van Gulik <di...@webweaving.org> het volgende geschreven:
>
> >
> > Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
> >
> >> I have pretty much completely rewritten every bit of code related to
> >> hostname verification in SVN trunk.
> >>
> >> https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
> >>
> >> I would truly appreciate someone doing a peer review of the changes
> >> and / or giving me feedback with regards to further improvements.
> >
> > - regex for the pattern
> >
> > From my read - it seems that you build with input under the user control if I am not mistaken - yet it could be more than mere characters.
> >
> > So I am a bit worried about revil regexes slipping in (e.g. ReDoS); and then causing some sort of exhaustion*.
> >
>
> Found that some of below are indeed able to hang the regex stack (e.g. # 2). However the more elaborate regex-es are blocked by:
>
> private final static Pattern WILDCARD_PATTERN = Pattern.compile( "^[a-z0-9\\-\\*]+(\\.[a-z0-9\\-]+){2,}$", Pattern.CASE_INSENSITIVE);
> ..
> WILDCARD_PATTERN.matcher(identity).matches()
>
> which we apply to the subjectAltName, CN, etc. So that is not too bad then - assuming that that regep does not let them through. Which is likely - as the only dangerous thing I see in there is a *.
>
Hi Dirk-Willem
Thank you so much for your feedback. What I could do is validate both
the identity and the subjectAltName pattern by making sure they consist
of characters legal for domain names (alphanumeric, dash and asterisk in
case of subjectAltName) prior to doing regexp matching with them.
> Obviously - as we get into UTF8 internationalized domain names - we may accidentally break that protection at some point.
>
Would not internationalized domain names be Punycode encoded instead?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: CVE-2014-3577 postmortem
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
Op 21 aug. 2014, om 17:50 heeft Dirk-Willem van Gulik <di...@webweaving.org> het volgende geschreven:
>
> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>
>> I have pretty much completely rewritten every bit of code related to
>> hostname verification in SVN trunk.
>>
>> https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>>
>> I would truly appreciate someone doing a peer review of the changes
>> and / or giving me feedback with regards to further improvements.
>
> - regex for the pattern
>
> From my read - it seems that you build with input under the user control if I am not mistaken - yet it could be more than mere characters.
>
> So I am a bit worried about revil regexes slipping in (e.g. ReDoS); and then causing some sort of exhaustion*.
>
Found that some of below are indeed able to hang the regex stack (e.g. # 2). However the more elaborate regex-es are blocked by:
private final static Pattern WILDCARD_PATTERN = Pattern.compile( "^[a-z0-9\\-\\*]+(\\.[a-z0-9\\-]+){2,}$", Pattern.CASE_INSENSITIVE);
..
WILDCARD_PATTERN.matcher(identity).matches()
which we apply to the subjectAltName, CN, etc. So that is not too bad then - assuming that that regep does not let them through. Which is likely - as the only dangerous thing I see in there is a *.
Obviously - as we get into UTF8 internationalized domain names - we may accidentally break that protection at some point.
Dw.
> Having said that - I tried a few obvious ones - and have not gotten a decent example yet.
>
> /**
> * Evil Regex example(s) / openssl req -new -x509 -nodes -keyout /dev/null -subj "/CN=^(([a-z])+.)+[A-Z]([a-z])+$"
> */
>
> public final static byte[] X509_EVIL_REGEX_1= (
> "-----BEGIN CERTIFICATE-----\n" +
> "MIICGjCCAYOgAwIBAgIJAOo56cPW09+fMA0GCSqGSIb3DQEBBQUAMCYxJDAiBgNV\n" +
> "BAMMG14oKFthLXpdKSsuKStbQS1aXShbYS16XSkrJDAeFw0xNDA4MjExMzAzMTVa\n" +
> "Fw0xNDA5MjAxMzAzMTVaMCYxJDAiBgNVBAMMG14oKFthLXpdKSsuKStbQS1aXShb\n" +
> "YS16XSkrJDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3Qo9S/QuEAmVnV9O\n" +
> "g7TsdUfjhV+szbCiia3S1Wyywmn70x7UOuxN05kEuYiQOljHk+lcLbZqFjkDoCde\n" +
> "3sTrYzocsDV1F44aoIDNf6FoTF4zvO5DrH5PQ7AXS0ot9QLwHbBbNnc8BUDUxcro\n" +
> "v4lpDbo7OHdneLPC3iMy6H+TTHUCAwEAAaNQME4wHQYDVR0OBBYEFER/UmoLTblm\n" +
> "HC4lnANRHTJJ81aBMB8GA1UdIwQYMBaAFER/UmoLTblmHC4lnANRHTJJ81aBMAwG\n" +
> "A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAQdpC4WQ15IN6lzaA0S3QjSRG\n" +
> "Sk9Ds4iepfM2xWDFI78oTtYvnffv0Ow+Yzs2QoDHVyRZO7IS9gBWAmGvVvZbTXJD\n" +
> "tNofNu074GddS9P1GSj+cd4XsX5pDW8QlYPupg3/5XV3l2i99Eo/EodP3U3WnZd7\n" +
> "pTUwN+iCW4sz516Tp40=\n" +
> "-----END CERTIFICATE-----").getBytes();
>
> public final static byte[] X509_EVIL_REGEX_2 = (
> "-----BEGIN CERTIFICATE-----\n" +
> "MIIB9jCCAV+gAwIBAgIJAKFcCPW2esygMA0GCSqGSIb3DQEBBQUAMBQxEjAQBgNV\n" +
> "BAMMCSguKmEpezMwfTAeFw0xNDA4MjExMzIxMDBaFw0xNDA5MjAxMzIxMDBaMBQx\n" +
> "EjAQBgNVBAMMCSguKmEpezMwfTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA\n" +
> "l4ajddWLAnNAbMkrInDgn5MH5bleFUm1Aq+HDxuBEmy1vabxoyV5GDexL9NquAsL\n" +
> "AxOLihWFMjG6NpPCB4rQa98vBSEaj2N+Yp4DTfS01INkOxxOQX+zNfh54GDeJfQS\n" +
> "0/+BdzZsGVhE6/ekPLh4He3MO9vC6hXaD79beIRdTN8CAwEAAaNQME4wHQYDVR0O\n" +
> "BBYEFODDhk2qLs0qraeXtwHBRE3C1VWPMB8GA1UdIwQYMBaAFODDhk2qLs0qraeX\n" +
> "twHBRE3C1VWPMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAQHwEiaOy\n" +
> "NMs8XbZfbovlXUDtIm20PiQ82TZHYb0kGd+UhcBfGMewi1wO2/ETYToVFbKaELTm\n" +
> "cQcad5TQM6KnACi1uZSJLLMO9eFT4sF9ZErcVPNPvszcE0K5PBWu7m4el7ZG4tOe\n" +
> "eMam4OzNiZpNy+9aXe4Zh4ZvxS/ReD7+PHM=\n" +
> "-----END CERTIFICATE-----").getBytes();
>
> public final static byte[] X509_EVIL_REGEX_3 = (
> "-----BEGIN CERTIFICATE-----\n" +
> "MIIB+DCCAWGgAwIBAgIJAJyEzt1ofEhdMA0GCSqGSIb3DQEBBQUAMBUxEzARBgNV\n" +
> "BAMMCihhYXxhYWI/KSswHhcNMTQwODIxMTQ1MzIwWhcNMTQwOTIwMTQ1MzIwWjAV\n" +
> "MRMwEQYDVQQDDAooYWF8YWFiPykrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB\n" +
> "gQC9XeUm4juhMbeqyMdUgU9Oiudec89Yp+68jfg1397w8yoSrxssUucicnpBS7Kf\n" +
> "M0JDy3E3CWSa/mphey9zS+rxxHE+p4u7h3uCZanTe4RcrkRy8jF4VdroDqugm+1T\n" +
> "PIV24mNFCsHQU7w4EiWLgvnxkCrBfFmpHEwOYp2GH7/E5QIDAQABo1AwTjAdBgNV\n" +
> "HQ4EFgQUdbxxDEpEMjiY0viM0EfNWWtZPIgwHwYDVR0jBBgwFoAUdbxxDEpEMjiY\n" +
> "0viM0EfNWWtZPIgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCuBjrr\n" +
> "Xdn9KxN5WMwLZ/K6zj403s7eia8Pl2SNofPj7V5t5vXbhCceM1g2NTy1XgB/remx\n" +
> "6o3V4Lw94uj3WFdp8UT3sL+PNUuUgg98zUgCcED9EMMU0mKdcHzrwjzZBTjQOF/I\n" +
> "ggNk2gVdv6awgBUel0hcWY9/F9a3pNWYMmFn5A==\n" +
> "-----END CERTIFICATE-----").getBytes();
>
> public final static byte[] X509_EVIL_REGEX_4 = (
> "-----BEGIN CERTIFICATE-----\n" +
> "MIIB8jCCAVugAwIBAgIJAPU+FLeLYdGUMA0GCSqGSIb3DQEBBQUAMBIxEDAOBgNV\n" +
> "BAMMB14oYSspKyQwHhcNMTQwODIxMTQ1NzExWhcNMTQwOTIwMTQ1NzExWjASMRAw\n" +
> "DgYDVQQDDAdeKGErKSskMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYIkgN\n" +
> "N4Y8ZCIjztOzuzqth7gObsuSR7BjWp4FTg9T6J2hfyBrxu1WZY/J/4b01VdJMNE5\n" +
> "yMQI9A49i229DSSXKssv9VsLNgRN5X2el4HQg9ibialgB6KUwmL+c2vv4hJ92mrc\n" +
> "lnr54CVsXmxgABYhShkWZqIuTyAUE2r1FVqQtQIDAQABo1AwTjAdBgNVHQ4EFgQU\n" +
> "36WZSogs45HIg7G8MWKfU+NsSBQwHwYDVR0jBBgwFoAU36WZSogs45HIg7G8MWKf\n" +
> "U+NsSBQwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBvzGB/5B4tF7dz\n" +
> "ME1AhudTbmHyuPAGhGg3DUpPBNNZHHgYS1zGpXgcDlOaXYuvFrb81sCVGNAhCijq\n" +
> "wMiQEwW2GWWKi7qNnj/W35OyVsXTchfRXuL75ZcVzABa8hdldijwhvFHev75X+HW\n" +
> "Nr5sa4rDYtwqkERMJCtSpE9lETID2A==\n" +
> "-----END CERTIFICATE-----").getBytes();
>
> public final static byte[] X509_EVIL_REGEX_5 = (
> "-----BEGIN CERTIFICATE-----\n" +
> "MIIB9DCCAV2gAwIBAgIJAJkLISjl9geAMA0GCSqGSIb3DQEBBQUAMBMxETAPBgNV\n" +
> "BAMMCCgqYSl7MzB9MB4XDTE0MDgyMTE1MDM1MFoXDTE0MDkyMDE1MDM1MFowEzER\n" +
> "MA8GA1UEAwwIKCphKXszMH0wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLH\n" +
> "GTkGbs0+/7AQoVYG/nHgSLmr9pnd5oAcOVp/ncN7csMrQab4ftfZNFrEsAseRNl5\n" +
> "5b1CD0hkz3+sfXdocNUZl7bmkpIqhyHqo2QULbR9j7fTH8IIDbsipMj45FS6gm3P\n" +
> "ryL6n99z2jxpkUu6MgR9FNO9uUer57idANstbJwjAgMBAAGjUDBOMB0GA1UdDgQW\n" +
> "BBTmSxwccA9GPyAF7qhlUF9XTghFzDAfBgNVHSMEGDAWgBTmSxwccA9GPyAF7qhl\n" +
> "UF9XTghFzDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBAEwPdipEPBGp\n" +
> "3ajUKj6Fq4AdI8lOZIFrghjSNDqRe2ANybjwETt/seYOAdIFxlhW2ALDp8mNJAKP\n" +
> "5s5aFjeNlUvQKmtLm2ZDIQ0GlrjXZ3R1et1Qwd9XPBGsHK8pmmJZB9pbqdWzVF+w\n" +
> "5cgEPhsWHxM16wVtFUIMskyhtlO+Ai/6\n" +
> "-----END CERTIFICATE-----").getBytes();
>
> public final static byte[] X509_EVIL_REGEX_6 = (
> "-----BEGIN CERTIFICATE-----\n" +
> "MIICVjCCAgCgAwIBAgIJAMskaCGIhO70MA0GCSqGSIb3DQEBBQUAMBIxEDAOBgNV\n" +
> "BAMMB2lnbm9yZWQwHhcNMTQwODIxMTUzNjA1WhcNMTQwOTIwMTUzNjA1WjASMRAw\n" +
> "DgYDVQQDDAdpZ25vcmVkMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANQg+BI6DYd0\n" +
> "RviglOAXhp58CKloK1pzenOugAJ8afCTszQVUzWN+cq5ZS0lxdLQ0WOS2jCDlJfW\n" +
> "j2XQOBLsuQUCAwEAAaOCATcwggEzMAsGA1UdDwQEAwIF4DAJBgNVHRMEAjAAMIIB\n" +
> "FwYDVR0RBIIBDjCCAQqgEAYDKgMEoAkMB14oYSspKySgEgYDKgMEoAsMCSguKmEp\n" +
> "ezMwfaARBgMqAwSgCgwIKCphKXszMH2gEwYDKgMEoAwMCihhYXxhYWI/KSuCFDEu\n" +
> "Mi4zLjQ7VVRGODpeKGErKSskghYxLjIuMy40O1VURjg6KC4qYSl7MzB9ghUxLjIu\n" +
> "My40O1VURjg6KCphKXszMH2CFzEuMi4zLjQ7VVRGODooYWF8YWFiPykrgRQxLjIu\n" +
> "My40O1VURjg6XihhKykrJIEWMS4yLjMuNDtVVEY4OiguKmEpezMwfYEVMS4yLjMu\n" +
> "NDtVVEY4OigqYSl7MzB9gRcxLjIuMy40O1VURjg6KGFhfGFhYj8pKzANBgkqhkiG\n" +
> "9w0BAQUFAANBAA+NxqNkEqYRWL0Z5940zk4ddZxgD4HnQiOcsEWm0Akys370T7iQ\n" +
> "KNiBrfnX7Uf8VF7ZkxmxXH39Xo6hIqHfTXo=\n" +
> "-----END CERTIFICATE-----").getBytes();
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by sebb <se...@gmail.com>.
On 28 August 2014 20:22, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-08-28 at 20:19 +0100, sebb wrote:
>> On 28 August 2014 20:11, Oleg Kalnichevski <ol...@apache.org> wrote:
>> > On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
>> >> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
>> >> > On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
>> >> >> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>> >> >>
>> >> >> > I have pretty much completely rewritten every bit of code related to
>> >> >> > hostname verification in SVN trunk.
>> >> >> >
>> >> >> > https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>> >> >> >
>> >> >> > I would truly appreciate someone doing a peer review of the changes
>> >> >> > and / or giving me feedback with regards to further improvements.
>> >> >>
>> >> >> Looks good. Couple of thoughts
>> >> >>
>> >> >> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>> >> >>
>> >> >> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
>> >> >>
>> >> >> https://publicsuffix.org/list/effective_tld_names.dat
>> >> >>
>> >> >
>> >> > Folks
>> >> >
>> >> > It turns out that we already have a substantial amount of code for
>> >> > publicsuffix.org support in our 'cookie' module. It was contributed by
>> >> > Ortwin 'Odi' Glueck some while ago.
>> >> >
>> >> > I would like to enhance the existing implementation and also extend its
>> >> > test coverage.
>> >> >
>> >> > There is a set of test scenarios distributed by Mozilla, which I would
>> >> > like to re-use
>> >> >
>> >> > http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>> >> >
>> >> > It is distributed as Creative Commons zero copyright. We can incorporate
>> >> > those test scenarios. Do we need to add attribution clause to our NOTICE
>> >> > and Zero Copyright license to our LICENSE file?
>> >> >
>> >> > What do you think?
>> >>
>> >> The rule for adding stuff to NOTICE is here:
>> >>
>> >> http://www.apache.org/legal/resolved.html#required-third-party-notices
>> >>
>> >> What is the exact wording of the license used by Mozilla?
>> >> Is there a URL for it?
>> >>
>> >
>> > The license can be found here:
>> >
>> > http://creativecommons.org/publicdomain/zero/1.0/
>>
>> That's not actually the license, nor does the link to the full text
>> appear to be the text of the license.
>>
>> I was after the link to the license details on the Mozilla site.
>>
>
> This is all we have [1]
>
> ---
> // Any copyright is dedicated to the Public Domain.
> // http://creativecommons.org/publicdomain/zero/1.0/
> ---
AFAICT, there is no attribution requirement so no need to update NOTICE.
However, it's not clear what needs to go in the LICENSE file as it is
not clear what the license text is.
> Oleg
>
> [1]
> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577
postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-08-28 at 20:19 +0100, sebb wrote:
> On 28 August 2014 20:11, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
> >> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
> >> > On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
> >> >> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
> >> >>
> >> >> > I have pretty much completely rewritten every bit of code related to
> >> >> > hostname verification in SVN trunk.
> >> >> >
> >> >> > https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
> >> >> >
> >> >> > I would truly appreciate someone doing a peer review of the changes
> >> >> > and / or giving me feedback with regards to further improvements.
> >> >>
> >> >> Looks good. Couple of thoughts
> >> >>
> >> >> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
> >> >>
> >> >> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
> >> >>
> >> >> https://publicsuffix.org/list/effective_tld_names.dat
> >> >>
> >> >
> >> > Folks
> >> >
> >> > It turns out that we already have a substantial amount of code for
> >> > publicsuffix.org support in our 'cookie' module. It was contributed by
> >> > Ortwin 'Odi' Glueck some while ago.
> >> >
> >> > I would like to enhance the existing implementation and also extend its
> >> > test coverage.
> >> >
> >> > There is a set of test scenarios distributed by Mozilla, which I would
> >> > like to re-use
> >> >
> >> > http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
> >> >
> >> > It is distributed as Creative Commons zero copyright. We can incorporate
> >> > those test scenarios. Do we need to add attribution clause to our NOTICE
> >> > and Zero Copyright license to our LICENSE file?
> >> >
> >> > What do you think?
> >>
> >> The rule for adding stuff to NOTICE is here:
> >>
> >> http://www.apache.org/legal/resolved.html#required-third-party-notices
> >>
> >> What is the exact wording of the license used by Mozilla?
> >> Is there a URL for it?
> >>
> >
> > The license can be found here:
> >
> > http://creativecommons.org/publicdomain/zero/1.0/
>
> That's not actually the license, nor does the link to the full text
> appear to be the text of the license.
>
> I was after the link to the license details on the Mozilla site.
>
This is all we have [1]
---
// Any copyright is dedicated to the Public Domain.
// http://creativecommons.org/publicdomain/zero/1.0/
---
Oleg
[1]
http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577
postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2014-08-29 at 12:15 +0200, Dirk-Willem van Gulik wrote:
> > On 29 Aug 2014, at 10:18, Oleg Kalnichevski <ol...@apache.org> wrote:
> >
> > On Thu, 2014-08-28 at 22:34 +0100, sebb wrote:
> >> On 28 August 2014 20:32, Asankha C. Perera <as...@apache.org> wrote:
> >
> > ...
> >
> >>> I think that is the legal text.. but for the NOTICE file we could possibly
> >>> use just the following two lines to keep it short?
> >>>
> >>>
> >>> // Any copyright is dedicated to the Public Domain.
> >>> // http://creativecommons.org/publicdomain/zero/1.0/
> >>>
> >>
> >> That would not be sufficient, as it is not clear to what the lines refer.
> >>
> >> However, we should not add anything to NOTICE unless it is _required_.
> >> This does not appear to be the case here.
> >>
> >> NOTICE is for _required_ attributions.
> >>
> >
> > What does this mean in plain English? We apparently are not required to
> > make a formal attribution to the original author. Can I go ahead and
> > copy the test data to HC test code tree?
>
>
> These things are not that black and white.
>
> Part of it is courtesy; part of it is leaving enough breadcrums for our peers
> 20+ year later -and- for our end users when they need to sort through IP
> issues.
>
> So I suggest that:
>
> - leave NOTICE as is - as it is for the more ‚you must read’ this
> sort of things.
>
> - Add a section in the LICENSE file -OR- a extra file in the publicsuffic
> directory in which you import the publicsuffix data which says
> something like:
>
> "
> These files/directory/XX have been included under a CC0 1.0
> Public Domain Dedication (url). The original can be found
> at url.
> „
>
> And in any case - put a note in the release notes. Especially if you go down the
> path of just a file with the directory as opposed to something at the end
> of the license file.
>
> That should make it easy for anyone to find the information reasonably easy; without
> cluttering things up too much.
>
> Thanks,
>
> Dw.
>
>
May all this licensing stuff burn in hell. I'll run the tests locally to
make sure our implementation is compliant but will not commit the tests
to the repository.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 29 Aug 2014, at 10:18, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Thu, 2014-08-28 at 22:34 +0100, sebb wrote:
>> On 28 August 2014 20:32, Asankha C. Perera <as...@apache.org> wrote:
>
> ...
>
>>> I think that is the legal text.. but for the NOTICE file we could possibly
>>> use just the following two lines to keep it short?
>>>
>>>
>>> // Any copyright is dedicated to the Public Domain.
>>> // http://creativecommons.org/publicdomain/zero/1.0/
>>>
>>
>> That would not be sufficient, as it is not clear to what the lines refer.
>>
>> However, we should not add anything to NOTICE unless it is _required_.
>> This does not appear to be the case here.
>>
>> NOTICE is for _required_ attributions.
>>
>
> What does this mean in plain English? We apparently are not required to
> make a formal attribution to the original author. Can I go ahead and
> copy the test data to HC test code tree?
These things are not that black and white.
Part of it is courtesy; part of it is leaving enough breadcrums for our peers
20+ year later -and- for our end users when they need to sort through IP
issues.
So I suggest that:
- leave NOTICE as is - as it is for the more ‚you must read’ this
sort of things.
- Add a section in the LICENSE file -OR- a extra file in the publicsuffic
directory in which you import the publicsuffix data which says
something like:
"
These files/directory/XX have been included under a CC0 1.0
Public Domain Dedication (url). The original can be found
at url.
„
And in any case - put a note in the release notes. Especially if you go down the
path of just a file with the directory as opposed to something at the end
of the license file.
That should make it easy for anyone to find the information reasonably easy; without
cluttering things up too much.
Thanks,
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577
postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-08-28 at 22:34 +0100, sebb wrote:
> On 28 August 2014 20:32, Asankha C. Perera <as...@apache.org> wrote:
...
> > I think that is the legal text.. but for the NOTICE file we could possibly
> > use just the following two lines to keep it short?
> >
> >
> > // Any copyright is dedicated to the Public Domain.
> > // http://creativecommons.org/publicdomain/zero/1.0/
> >
>
> That would not be sufficient, as it is not clear to what the lines refer.
>
> However, we should not add anything to NOTICE unless it is _required_.
> This does not appear to be the case here.
>
> NOTICE is for _required_ attributions.
>
Sebastian,
What does this mean in plain English? We apparently are not required to
make a formal attribution to the original author. Can I go ahead and
copy the test data to HC test code tree?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by sebb <se...@gmail.com>.
On 28 August 2014 20:32, Asankha C. Perera <as...@apache.org> wrote:
> On 08/29/2014 12:49 AM, sebb wrote:
>>
>> On 28 August 2014 20:11, Oleg Kalnichevski <ol...@apache.org> wrote:
>>>
>>> On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
>>>>
>>>> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
>>>>>
>>>>> On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
>>>>>>
>>>>>> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org>
>>>>>> het volgende geschreven:
>>>>>>
>>>>>>> I have pretty much completely rewritten every bit of code related to
>>>>>>> hostname verification in SVN trunk.
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>>>>>>>
>>>>>>> I would truly appreciate someone doing a peer review of the changes
>>>>>>> and / or giving me feedback with regards to further improvements.
>>>>>>
>>>>>> Looks good. Couple of thoughts
>>>>>>
>>>>>> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>>>>>>
>>>>>> My guess is that longer term you will get too many specials - and the
>>>>>> end game is parsing something like https://publicsuffix.org/ and
>>>>>> specifically
>>>>>>
>>>>>> https://publicsuffix.org/list/effective_tld_names.dat
>>>>>>
>>>>> Folks
>>>>>
>>>>> It turns out that we already have a substantial amount of code for
>>>>> publicsuffix.org support in our 'cookie' module. It was contributed by
>>>>> Ortwin 'Odi' Glueck some while ago.
>>>>>
>>>>> I would like to enhance the existing implementation and also extend its
>>>>> test coverage.
>>>>>
>>>>> There is a set of test scenarios distributed by Mozilla, which I would
>>>>> like to re-use
>>>>>
>>>>>
>>>>> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>>>>>
>>>>> It is distributed as Creative Commons zero copyright. We can
>>>>> incorporate
>>>>> those test scenarios. Do we need to add attribution clause to our
>>>>> NOTICE
>>>>> and Zero Copyright license to our LICENSE file?
>>>>>
>>>>> What do you think?
>>>>
>>>> The rule for adding stuff to NOTICE is here:
>>>>
>>>> http://www.apache.org/legal/resolved.html#required-third-party-notices
>>>>
>>>> What is the exact wording of the license used by Mozilla?
>>>> Is there a URL for it?
>>>>
>>> The license can be found here:
>>>
>>> http://creativecommons.org/publicdomain/zero/1.0/
>>
>> That's not actually the license, nor does the link to the full text
>> appear to be the text of the license.
>>
>> I was after the link to the license details on the Mozilla site.
>
> I think that is the legal text.. but for the NOTICE file we could possibly
> use just the following two lines to keep it short?
>
>
> // Any copyright is dedicated to the Public Domain.
> // http://creativecommons.org/publicdomain/zero/1.0/
>
That would not be sufficient, as it is not clear to what the lines refer.
However, we should not add anything to NOTICE unless it is _required_.
This does not appear to be the case here.
NOTICE is for _required_ attributions.
> asankha
>
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by "Asankha C. Perera" <as...@apache.org>.
On 08/29/2014 12:49 AM, sebb wrote:
> On 28 August 2014 20:11, Oleg Kalnichevski <ol...@apache.org> wrote:
>> On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
>>> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
>>>> On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
>>>>> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>>>>>
>>>>>> I have pretty much completely rewritten every bit of code related to
>>>>>> hostname verification in SVN trunk.
>>>>>>
>>>>>> https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>>>>>>
>>>>>> I would truly appreciate someone doing a peer review of the changes
>>>>>> and / or giving me feedback with regards to further improvements.
>>>>> Looks good. Couple of thoughts
>>>>>
>>>>> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>>>>>
>>>>> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
>>>>>
>>>>> https://publicsuffix.org/list/effective_tld_names.dat
>>>>>
>>>> Folks
>>>>
>>>> It turns out that we already have a substantial amount of code for
>>>> publicsuffix.org support in our 'cookie' module. It was contributed by
>>>> Ortwin 'Odi' Glueck some while ago.
>>>>
>>>> I would like to enhance the existing implementation and also extend its
>>>> test coverage.
>>>>
>>>> There is a set of test scenarios distributed by Mozilla, which I would
>>>> like to re-use
>>>>
>>>> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>>>>
>>>> It is distributed as Creative Commons zero copyright. We can incorporate
>>>> those test scenarios. Do we need to add attribution clause to our NOTICE
>>>> and Zero Copyright license to our LICENSE file?
>>>>
>>>> What do you think?
>>> The rule for adding stuff to NOTICE is here:
>>>
>>> http://www.apache.org/legal/resolved.html#required-third-party-notices
>>>
>>> What is the exact wording of the license used by Mozilla?
>>> Is there a URL for it?
>>>
>> The license can be found here:
>>
>> http://creativecommons.org/publicdomain/zero/1.0/
> That's not actually the license, nor does the link to the full text
> appear to be the text of the license.
>
> I was after the link to the license details on the Mozilla site.
I think that is the legal text.. but for the NOTICE file we could
possibly use just the following two lines to keep it short?
// Any copyright is dedicated to the Public Domain.
// http://creativecommons.org/publicdomain/zero/1.0/
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by sebb <se...@gmail.com>.
On 28 August 2014 20:11, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
>> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
>> > On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
>> >> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>> >>
>> >> > I have pretty much completely rewritten every bit of code related to
>> >> > hostname verification in SVN trunk.
>> >> >
>> >> > https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>> >> >
>> >> > I would truly appreciate someone doing a peer review of the changes
>> >> > and / or giving me feedback with regards to further improvements.
>> >>
>> >> Looks good. Couple of thoughts
>> >>
>> >> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>> >>
>> >> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
>> >>
>> >> https://publicsuffix.org/list/effective_tld_names.dat
>> >>
>> >
>> > Folks
>> >
>> > It turns out that we already have a substantial amount of code for
>> > publicsuffix.org support in our 'cookie' module. It was contributed by
>> > Ortwin 'Odi' Glueck some while ago.
>> >
>> > I would like to enhance the existing implementation and also extend its
>> > test coverage.
>> >
>> > There is a set of test scenarios distributed by Mozilla, which I would
>> > like to re-use
>> >
>> > http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>> >
>> > It is distributed as Creative Commons zero copyright. We can incorporate
>> > those test scenarios. Do we need to add attribution clause to our NOTICE
>> > and Zero Copyright license to our LICENSE file?
>> >
>> > What do you think?
>>
>> The rule for adding stuff to NOTICE is here:
>>
>> http://www.apache.org/legal/resolved.html#required-third-party-notices
>>
>> What is the exact wording of the license used by Mozilla?
>> Is there a URL for it?
>>
>
> The license can be found here:
>
> http://creativecommons.org/publicdomain/zero/1.0/
That's not actually the license, nor does the link to the full text
appear to be the text of the license.
I was after the link to the license details on the Mozilla site.
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by sebb <se...@gmail.com>.
On 28 August 2014 20:18, Asankha C. Perera <as...@apache.org> wrote:
> On 08/29/2014 12:41 AM, Oleg Kalnichevski wrote:
>>
>> On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
>>>
>>> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
>>>>
>>>> On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
>>>>>
>>>>> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org>
>>>>> het volgende geschreven:
>>>>>
>>>>>> I have pretty much completely rewritten every bit of code related to
>>>>>> hostname verification in SVN trunk.
>>>>>>
>>>>>>
>>>>>> https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>>>>>>
>>>>>> I would truly appreciate someone doing a peer review of the changes
>>>>>> and / or giving me feedback with regards to further improvements.
>>>>>
>>>>> Looks good. Couple of thoughts
>>>>>
>>>>> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>>>>>
>>>>> My guess is that longer term you will get too many specials - and the
>>>>> end game is parsing something like https://publicsuffix.org/ and
>>>>> specifically
>>>>>
>>>>> https://publicsuffix.org/list/effective_tld_names.dat
>>>>>
>>>> Folks
>>>>
>>>> It turns out that we already have a substantial amount of code for
>>>> publicsuffix.org support in our 'cookie' module. It was contributed by
>>>> Ortwin 'Odi' Glueck some while ago.
>>>>
>>>> I would like to enhance the existing implementation and also extend its
>>>> test coverage.
>>>>
>>>> There is a set of test scenarios distributed by Mozilla, which I would
>>>> like to re-use
>>>>
>>>>
>>>> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>>>>
>>>> It is distributed as Creative Commons zero copyright. We can incorporate
>>>> those test scenarios. Do we need to add attribution clause to our NOTICE
>>>> and Zero Copyright license to our LICENSE file?
>>>>
>>>> What do you think?
>>>
>>> The rule for adding stuff to NOTICE is here:
>>>
>>> http://www.apache.org/legal/resolved.html#required-third-party-notices
>>>
>>> What is the exact wording of the license used by Mozilla?
>>> Is there a URL for it?
>>>
>> The license can be found here:
>>
>> http://creativecommons.org/publicdomain/zero/1.0/
>
> I think it would be safer to add to NOTICE and LICENSE files
NOTICE is for _required_ attributions only.
NOTICE has to be passed on to downstream consumers so must be as short
as possible.
> regards
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by "Asankha C. Perera" <as...@apache.org>.
On 08/29/2014 12:41 AM, Oleg Kalnichevski wrote:
> On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
>> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
>>> On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
>>>> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>>>>
>>>>> I have pretty much completely rewritten every bit of code related to
>>>>> hostname verification in SVN trunk.
>>>>>
>>>>> https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>>>>>
>>>>> I would truly appreciate someone doing a peer review of the changes
>>>>> and / or giving me feedback with regards to further improvements.
>>>> Looks good. Couple of thoughts
>>>>
>>>> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>>>>
>>>> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
>>>>
>>>> https://publicsuffix.org/list/effective_tld_names.dat
>>>>
>>> Folks
>>>
>>> It turns out that we already have a substantial amount of code for
>>> publicsuffix.org support in our 'cookie' module. It was contributed by
>>> Ortwin 'Odi' Glueck some while ago.
>>>
>>> I would like to enhance the existing implementation and also extend its
>>> test coverage.
>>>
>>> There is a set of test scenarios distributed by Mozilla, which I would
>>> like to re-use
>>>
>>> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>>>
>>> It is distributed as Creative Commons zero copyright. We can incorporate
>>> those test scenarios. Do we need to add attribution clause to our NOTICE
>>> and Zero Copyright license to our LICENSE file?
>>>
>>> What do you think?
>> The rule for adding stuff to NOTICE is here:
>>
>> http://www.apache.org/legal/resolved.html#required-third-party-notices
>>
>> What is the exact wording of the license used by Mozilla?
>> Is there a URL for it?
>>
> The license can be found here:
>
> http://creativecommons.org/publicdomain/zero/1.0/
I think it would be safer to add to NOTICE and LICENSE files
regards
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577
postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-08-28 at 16:51 +0100, sebb wrote:
> On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
> >> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
> >>
> >> > I have pretty much completely rewritten every bit of code related to
> >> > hostname verification in SVN trunk.
> >> >
> >> > https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
> >> >
> >> > I would truly appreciate someone doing a peer review of the changes
> >> > and / or giving me feedback with regards to further improvements.
> >>
> >> Looks good. Couple of thoughts
> >>
> >> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
> >>
> >> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
> >>
> >> https://publicsuffix.org/list/effective_tld_names.dat
> >>
> >
> > Folks
> >
> > It turns out that we already have a substantial amount of code for
> > publicsuffix.org support in our 'cookie' module. It was contributed by
> > Ortwin 'Odi' Glueck some while ago.
> >
> > I would like to enhance the existing implementation and also extend its
> > test coverage.
> >
> > There is a set of test scenarios distributed by Mozilla, which I would
> > like to re-use
> >
> > http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
> >
> > It is distributed as Creative Commons zero copyright. We can incorporate
> > those test scenarios. Do we need to add attribution clause to our NOTICE
> > and Zero Copyright license to our LICENSE file?
> >
> > What do you think?
>
> The rule for adding stuff to NOTICE is here:
>
> http://www.apache.org/legal/resolved.html#required-third-party-notices
>
> What is the exact wording of the license used by Mozilla?
> Is there a URL for it?
>
The license can be found here:
http://creativecommons.org/publicdomain/zero/1.0/
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: [Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by sebb <se...@gmail.com>.
On 28 August 2014 10:20, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
>> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>>
>> > I have pretty much completely rewritten every bit of code related to
>> > hostname verification in SVN trunk.
>> >
>> > https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>> >
>> > I would truly appreciate someone doing a peer review of the changes
>> > and / or giving me feedback with regards to further improvements.
>>
>> Looks good. Couple of thoughts
>>
>> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>>
>> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
>>
>> https://publicsuffix.org/list/effective_tld_names.dat
>>
>
> Folks
>
> It turns out that we already have a substantial amount of code for
> publicsuffix.org support in our 'cookie' module. It was contributed by
> Ortwin 'Odi' Glueck some while ago.
>
> I would like to enhance the existing implementation and also extend its
> test coverage.
>
> There is a set of test scenarios distributed by Mozilla, which I would
> like to re-use
>
> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
>
> It is distributed as Creative Commons zero copyright. We can incorporate
> those test scenarios. Do we need to add attribution clause to our NOTICE
> and Zero Copyright license to our LICENSE file?
>
> What do you think?
The rule for adding stuff to NOTICE is here:
http://www.apache.org/legal/resolved.html#required-third-party-notices
What is the exact wording of the license used by Mozilla?
Is there a URL for it?
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[Legal] publicsuffix.org test data; was Re: CVE-2014-3577 postmortem
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-08-21 at 17:50 +0200, Dirk-Willem van Gulik wrote:
> Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
>
> > I have pretty much completely rewritten every bit of code related to
> > hostname verification in SVN trunk.
> >
> > https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
> >
> > I would truly appreciate someone doing a peer review of the changes
> > and / or giving me feedback with regards to further improvements.
>
> Looks good. Couple of thoughts
>
> - BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
>
> My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
>
> https://publicsuffix.org/list/effective_tld_names.dat
>
Folks
It turns out that we already have a substantial amount of code for
publicsuffix.org support in our 'cookie' module. It was contributed by
Ortwin 'Odi' Glueck some while ago.
I would like to enhance the existing implementation and also extend its
test coverage.
There is a set of test scenarios distributed by Mozilla, which I would
like to re-use
http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1
It is distributed as Creative Commons zero copyright. We can incorporate
those test scenarios. Do we need to add attribution clause to our NOTICE
and Zero Copyright license to our LICENSE file?
What do you think?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: CVE-2014-3577 postmortem
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
Op 21 aug. 2014, om 15:26 heeft Oleg Kalnichevski <ol...@apache.org> het volgende geschreven:
> I have pretty much completely rewritten every bit of code related to
> hostname verification in SVN trunk.
>
> https://github.com/apache/httpclient/tree/268d6cc113b305addc4a31a70bd7c3b6d545e337/httpclient/src/main/java/org/apache/http/conn/ssl
>
> I would truly appreciate someone doing a peer review of the changes
> and / or giving me feedback with regards to further improvements.
Looks good. Couple of thoughts
- BAD_COUNTRY_2LDS, BAD_COUNTRY_WILDCARD_PATTERN
My guess is that longer term you will get too many specials - and the end game is parsing something like https://publicsuffix.org/ and specifically
https://publicsuffix.org/list/effective_tld_names.dat
to get the depth right.
- regex for the pattern
From my read - it seems that you build with input under the user control if I am not mistaken - yet it could be more than mere characters.
So I am a bit worried about revil regexes slipping in (e.g. ReDoS); and then causing some sort of exhaustion*.
- countDots function
Prolly no longer used.
Dw.
Having said that - I tried a few obvious ones - and have not gotten a decent example yet.
/**
* Evil Regex example(s) / openssl req -new -x509 -nodes -keyout /dev/null -subj "/CN=^(([a-z])+.)+[A-Z]([a-z])+$"
*/
public final static byte[] X509_EVIL_REGEX_1= (
"-----BEGIN CERTIFICATE-----\n" +
"MIICGjCCAYOgAwIBAgIJAOo56cPW09+fMA0GCSqGSIb3DQEBBQUAMCYxJDAiBgNV\n" +
"BAMMG14oKFthLXpdKSsuKStbQS1aXShbYS16XSkrJDAeFw0xNDA4MjExMzAzMTVa\n" +
"Fw0xNDA5MjAxMzAzMTVaMCYxJDAiBgNVBAMMG14oKFthLXpdKSsuKStbQS1aXShb\n" +
"YS16XSkrJDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3Qo9S/QuEAmVnV9O\n" +
"g7TsdUfjhV+szbCiia3S1Wyywmn70x7UOuxN05kEuYiQOljHk+lcLbZqFjkDoCde\n" +
"3sTrYzocsDV1F44aoIDNf6FoTF4zvO5DrH5PQ7AXS0ot9QLwHbBbNnc8BUDUxcro\n" +
"v4lpDbo7OHdneLPC3iMy6H+TTHUCAwEAAaNQME4wHQYDVR0OBBYEFER/UmoLTblm\n" +
"HC4lnANRHTJJ81aBMB8GA1UdIwQYMBaAFER/UmoLTblmHC4lnANRHTJJ81aBMAwG\n" +
"A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAQdpC4WQ15IN6lzaA0S3QjSRG\n" +
"Sk9Ds4iepfM2xWDFI78oTtYvnffv0Ow+Yzs2QoDHVyRZO7IS9gBWAmGvVvZbTXJD\n" +
"tNofNu074GddS9P1GSj+cd4XsX5pDW8QlYPupg3/5XV3l2i99Eo/EodP3U3WnZd7\n" +
"pTUwN+iCW4sz516Tp40=\n" +
"-----END CERTIFICATE-----").getBytes();
public final static byte[] X509_EVIL_REGEX_2 = (
"-----BEGIN CERTIFICATE-----\n" +
"MIIB9jCCAV+gAwIBAgIJAKFcCPW2esygMA0GCSqGSIb3DQEBBQUAMBQxEjAQBgNV\n" +
"BAMMCSguKmEpezMwfTAeFw0xNDA4MjExMzIxMDBaFw0xNDA5MjAxMzIxMDBaMBQx\n" +
"EjAQBgNVBAMMCSguKmEpezMwfTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA\n" +
"l4ajddWLAnNAbMkrInDgn5MH5bleFUm1Aq+HDxuBEmy1vabxoyV5GDexL9NquAsL\n" +
"AxOLihWFMjG6NpPCB4rQa98vBSEaj2N+Yp4DTfS01INkOxxOQX+zNfh54GDeJfQS\n" +
"0/+BdzZsGVhE6/ekPLh4He3MO9vC6hXaD79beIRdTN8CAwEAAaNQME4wHQYDVR0O\n" +
"BBYEFODDhk2qLs0qraeXtwHBRE3C1VWPMB8GA1UdIwQYMBaAFODDhk2qLs0qraeX\n" +
"twHBRE3C1VWPMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAQHwEiaOy\n" +
"NMs8XbZfbovlXUDtIm20PiQ82TZHYb0kGd+UhcBfGMewi1wO2/ETYToVFbKaELTm\n" +
"cQcad5TQM6KnACi1uZSJLLMO9eFT4sF9ZErcVPNPvszcE0K5PBWu7m4el7ZG4tOe\n" +
"eMam4OzNiZpNy+9aXe4Zh4ZvxS/ReD7+PHM=\n" +
"-----END CERTIFICATE-----").getBytes();
public final static byte[] X509_EVIL_REGEX_3 = (
"-----BEGIN CERTIFICATE-----\n" +
"MIIB+DCCAWGgAwIBAgIJAJyEzt1ofEhdMA0GCSqGSIb3DQEBBQUAMBUxEzARBgNV\n" +
"BAMMCihhYXxhYWI/KSswHhcNMTQwODIxMTQ1MzIwWhcNMTQwOTIwMTQ1MzIwWjAV\n" +
"MRMwEQYDVQQDDAooYWF8YWFiPykrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB\n" +
"gQC9XeUm4juhMbeqyMdUgU9Oiudec89Yp+68jfg1397w8yoSrxssUucicnpBS7Kf\n" +
"M0JDy3E3CWSa/mphey9zS+rxxHE+p4u7h3uCZanTe4RcrkRy8jF4VdroDqugm+1T\n" +
"PIV24mNFCsHQU7w4EiWLgvnxkCrBfFmpHEwOYp2GH7/E5QIDAQABo1AwTjAdBgNV\n" +
"HQ4EFgQUdbxxDEpEMjiY0viM0EfNWWtZPIgwHwYDVR0jBBgwFoAUdbxxDEpEMjiY\n" +
"0viM0EfNWWtZPIgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCuBjrr\n" +
"Xdn9KxN5WMwLZ/K6zj403s7eia8Pl2SNofPj7V5t5vXbhCceM1g2NTy1XgB/remx\n" +
"6o3V4Lw94uj3WFdp8UT3sL+PNUuUgg98zUgCcED9EMMU0mKdcHzrwjzZBTjQOF/I\n" +
"ggNk2gVdv6awgBUel0hcWY9/F9a3pNWYMmFn5A==\n" +
"-----END CERTIFICATE-----").getBytes();
public final static byte[] X509_EVIL_REGEX_4 = (
"-----BEGIN CERTIFICATE-----\n" +
"MIIB8jCCAVugAwIBAgIJAPU+FLeLYdGUMA0GCSqGSIb3DQEBBQUAMBIxEDAOBgNV\n" +
"BAMMB14oYSspKyQwHhcNMTQwODIxMTQ1NzExWhcNMTQwOTIwMTQ1NzExWjASMRAw\n" +
"DgYDVQQDDAdeKGErKSskMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYIkgN\n" +
"N4Y8ZCIjztOzuzqth7gObsuSR7BjWp4FTg9T6J2hfyBrxu1WZY/J/4b01VdJMNE5\n" +
"yMQI9A49i229DSSXKssv9VsLNgRN5X2el4HQg9ibialgB6KUwmL+c2vv4hJ92mrc\n" +
"lnr54CVsXmxgABYhShkWZqIuTyAUE2r1FVqQtQIDAQABo1AwTjAdBgNVHQ4EFgQU\n" +
"36WZSogs45HIg7G8MWKfU+NsSBQwHwYDVR0jBBgwFoAU36WZSogs45HIg7G8MWKf\n" +
"U+NsSBQwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBvzGB/5B4tF7dz\n" +
"ME1AhudTbmHyuPAGhGg3DUpPBNNZHHgYS1zGpXgcDlOaXYuvFrb81sCVGNAhCijq\n" +
"wMiQEwW2GWWKi7qNnj/W35OyVsXTchfRXuL75ZcVzABa8hdldijwhvFHev75X+HW\n" +
"Nr5sa4rDYtwqkERMJCtSpE9lETID2A==\n" +
"-----END CERTIFICATE-----").getBytes();
public final static byte[] X509_EVIL_REGEX_5 = (
"-----BEGIN CERTIFICATE-----\n" +
"MIIB9DCCAV2gAwIBAgIJAJkLISjl9geAMA0GCSqGSIb3DQEBBQUAMBMxETAPBgNV\n" +
"BAMMCCgqYSl7MzB9MB4XDTE0MDgyMTE1MDM1MFoXDTE0MDkyMDE1MDM1MFowEzER\n" +
"MA8GA1UEAwwIKCphKXszMH0wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLH\n" +
"GTkGbs0+/7AQoVYG/nHgSLmr9pnd5oAcOVp/ncN7csMrQab4ftfZNFrEsAseRNl5\n" +
"5b1CD0hkz3+sfXdocNUZl7bmkpIqhyHqo2QULbR9j7fTH8IIDbsipMj45FS6gm3P\n" +
"ryL6n99z2jxpkUu6MgR9FNO9uUer57idANstbJwjAgMBAAGjUDBOMB0GA1UdDgQW\n" +
"BBTmSxwccA9GPyAF7qhlUF9XTghFzDAfBgNVHSMEGDAWgBTmSxwccA9GPyAF7qhl\n" +
"UF9XTghFzDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBAEwPdipEPBGp\n" +
"3ajUKj6Fq4AdI8lOZIFrghjSNDqRe2ANybjwETt/seYOAdIFxlhW2ALDp8mNJAKP\n" +
"5s5aFjeNlUvQKmtLm2ZDIQ0GlrjXZ3R1et1Qwd9XPBGsHK8pmmJZB9pbqdWzVF+w\n" +
"5cgEPhsWHxM16wVtFUIMskyhtlO+Ai/6\n" +
"-----END CERTIFICATE-----").getBytes();
public final static byte[] X509_EVIL_REGEX_6 = (
"-----BEGIN CERTIFICATE-----\n" +
"MIICVjCCAgCgAwIBAgIJAMskaCGIhO70MA0GCSqGSIb3DQEBBQUAMBIxEDAOBgNV\n" +
"BAMMB2lnbm9yZWQwHhcNMTQwODIxMTUzNjA1WhcNMTQwOTIwMTUzNjA1WjASMRAw\n" +
"DgYDVQQDDAdpZ25vcmVkMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANQg+BI6DYd0\n" +
"RviglOAXhp58CKloK1pzenOugAJ8afCTszQVUzWN+cq5ZS0lxdLQ0WOS2jCDlJfW\n" +
"j2XQOBLsuQUCAwEAAaOCATcwggEzMAsGA1UdDwQEAwIF4DAJBgNVHRMEAjAAMIIB\n" +
"FwYDVR0RBIIBDjCCAQqgEAYDKgMEoAkMB14oYSspKySgEgYDKgMEoAsMCSguKmEp\n" +
"ezMwfaARBgMqAwSgCgwIKCphKXszMH2gEwYDKgMEoAwMCihhYXxhYWI/KSuCFDEu\n" +
"Mi4zLjQ7VVRGODpeKGErKSskghYxLjIuMy40O1VURjg6KC4qYSl7MzB9ghUxLjIu\n" +
"My40O1VURjg6KCphKXszMH2CFzEuMi4zLjQ7VVRGODooYWF8YWFiPykrgRQxLjIu\n" +
"My40O1VURjg6XihhKykrJIEWMS4yLjMuNDtVVEY4OiguKmEpezMwfYEVMS4yLjMu\n" +
"NDtVVEY4OigqYSl7MzB9gRcxLjIuMy40O1VURjg6KGFhfGFhYj8pKzANBgkqhkiG\n" +
"9w0BAQUFAANBAA+NxqNkEqYRWL0Z5940zk4ddZxgD4HnQiOcsEWm0Akys370T7iQ\n" +
"KNiBrfnX7Uf8VF7ZkxmxXH39Xo6hIqHfTXo=\n" +
"-----END CERTIFICATE-----").getBytes();
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org