org.apache.subversion.javahl.ClientException: Found invalid algorithm in certificate

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

org.apache.subversion.javahl.ClientException: Found invalid algorithm in certificate

Marc Strapetz-2
One of our users is encountering following exception:

svn: Java exception
svn: Wrapped Java Exception
   at org.apache.subversion.javahl.remote.RemoteFactory.open
   (Native Method)
   at org.apache.subversion.javahl.remote.RemoteFactory.openRemoteSession
   (RemoteFactory.java:228)
   ...
Caused by: org.apache.subversion.javahl.ClientException: Found invalid
algorithm in certificate
Unexpected ASN1 tag
   ...

with Subversion 1.9.7. He writes that command line client works fine for
him. It warns about the certificate not being "issued by a trusted
authority" and then shows the expected "(R)eject, accept (t)emporarily
or accept (p)ermanently?" question.

This happens on Linux.

Any ideas why command line client and JavaHL might behave differently here?

Note that the command line binaries are not identical to the JavaHL
binaries, but both have been compiled from Subversion 1.9.7. Could this
be a problem in our build process?

-Marc







Reply | Threaded
Open this post in threaded view
|

Re: org.apache.subversion.javahl.ClientException: Found invalid algorithm in certificate

Julian Foad-5
Ping! Anyone? (I noticed this message had no response on the list so far.)

Marc, please let us know if you learnt any more about this problem.

Thanks,
- Julian


Marc Strapetz wrote:

> One of our users is encountering following exception:
>
> svn: Java exception
> svn: Wrapped Java Exception
>    at org.apache.subversion.javahl.remote.RemoteFactory.open
>    (Native Method)
>    at org.apache.subversion.javahl.remote.RemoteFactory.openRemoteSession
>    (RemoteFactory.java:228)
>    ...
> Caused by: org.apache.subversion.javahl.ClientException: Found invalid
> algorithm in certificate
> Unexpected ASN1 tag
>    ...
>
> with Subversion 1.9.7. He writes that command line client works fine for
> him. It warns about the certificate not being "issued by a trusted
> authority" and then shows the expected "(R)eject, accept (t)emporarily
> or accept (p)ermanently?" question.
>
> This happens on Linux.
>
> Any ideas why command line client and JavaHL might behave differently here?
>
> Note that the command line binaries are not identical to the JavaHL
> binaries, but both have been compiled from Subversion 1.9.7. Could this
> be a problem in our build process?
>
> -Marc

Reply | Threaded
Open this post in threaded view
|

Re: org.apache.subversion.javahl.ClientException: Found invalid algorithm in certificate

Marc Strapetz-2
> Marc, please let us know if you learnt any more about this problem.

Unfortunately we didn't make progress here since my posting.

-Marc


On 02.01.2018 11:26, Julian Foad wrote:

> Ping! Anyone? (I noticed this message had no response on the list so far.)
>
> Marc, please let us know if you learnt any more about this problem.
>
> Thanks,
> - Julian
>
>
> Marc Strapetz wrote:
>> One of our users is encountering following exception:
>>
>> svn: Java exception
>> svn: Wrapped Java Exception
>>    at org.apache.subversion.javahl.remote.RemoteFactory.open
>>    (Native Method)
>>    at org.apache.subversion.javahl.remote.RemoteFactory.openRemoteSession
>>    (RemoteFactory.java:228)
>>    ...
>> Caused by: org.apache.subversion.javahl.ClientException: Found invalid
>> algorithm in certificate
>> Unexpected ASN1 tag
>>    ...
>>
>> with Subversion 1.9.7. He writes that command line client works fine
>> for him. It warns about the certificate not being "issued by a trusted
>> authority" and then shows the expected "(R)eject, accept (t)emporarily
>> or accept (p)ermanently?" question.
>>
>> This happens on Linux.
>>
>> Any ideas why command line client and JavaHL might behave differently
>> here?
>>
>> Note that the command line binaries are not identical to the JavaHL
>> binaries, but both have been compiled from Subversion 1.9.7. Could
>> this be a problem in our build process?
>>
>> -Marc
>
>
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.subversion.javahl.ClientException: Found invalid algorithm in certificate

Philip Martin
Marc Strapetz <[hidden email]> writes:

>> Marc, please let us know if you learnt any more about this problem.
>
> Unfortunately we didn't make progress here since my posting.

I have just fixed a bug in the JavaHL implementation of SSL trust
prompting, see r1820718.  I don't know if applies in your case, but it
might if the client was attempting to accept the cert failures
temporarily.

--
Philip
Reply | Threaded
Open this post in threaded view
|

Re: org.apache.subversion.javahl.ClientException: Found invalid algorithm in certificate

Marc Strapetz-2
On 10.01.2018 02:44, Philip Martin wrote:

> Marc Strapetz <[hidden email]> writes:
>
>>> Marc, please let us know if you learnt any more about this problem.
>>
>> Unfortunately we didn't make progress here since my posting.
>
> I have just fixed a bug in the JavaHL implementation of SSL trust
> prompting, see r1820718.  I don't know if applies in your case, but it
> might if the client was attempting to accept the cert failures
> temporarily.

We have cherry-picked your fix onto 1.9.7 tag but unfortunately it
doesn't solve the problem for the user.

-Marc

Reply | Threaded
Open this post in threaded view
|

x509 AlgorithmIdentifier parameters

Philip Martin
Marc Strapetz <[hidden email]> writes:

> We have cherry-picked your fix onto 1.9.7 tag but unfortunately it
> doesn't solve the problem for the user.

Looking back at the original mail it looks as if the error is produced
by x509parse.c:x509_get_alg() via svn_x509_parse_cert(), in particular
it is probably this assumption:

  /*
   * assume the algorithm parameters must be NULL
   */
  err = asn1_get_tag(p, end, &len, ASN1_NULL);
  if (err)
    return svn_error_create(SVN_ERR_X509_CERT_INVALID_ALG, err, NULL);

  if (*p != end)
    {
      err = svn_error_create(SVN_ERR_ASN1_LENGTH_MISMATCH, NULL, NULL);
      return svn_error_create(SVN_ERR_X509_CERT_INVALID_ALG, err, NULL);
    }

The failing cert probably provides non-NULL "algorithm parameters".

I suspect the reason the command line client "works" while your Java
code fails is that the command line client only invokes x509_get_alg()
for the "svn auth" operation, and then only if the cert has been
permanently stored as a failure exception.  Your Java code is probably
using svn_x509_parse_cert() as part of handling cert failures in more
cases, perhaps all operations.

Can you make the cert in question available, either on list or to me?

The fix is for our code to allow and parse the "algorithm parameters"
but I'm not sure what our code should do with the parsed values.  We
currently compare algorithms for equality using x509parse.c:oid_equal(),
perhaps we should be checking the parameters are equal as well?

--
Philip
Reply | Threaded
Open this post in threaded view
|

Re: x509 AlgorithmIdentifier parameters

Philip Martin
Philip Martin <[hidden email]> writes:

> Looking back at the original mail it looks as if the error is produced
> by x509parse.c:x509_get_alg() via svn_x509_parse_cert(), in particular
> it is probably this assumption:
>
>   /*
>    * assume the algorithm parameters must be NULL
>    */
>   err = asn1_get_tag(p, end, &len, ASN1_NULL);
>   if (err)
>     return svn_error_create(SVN_ERR_X509_CERT_INVALID_ALG, err, NULL);
>
>   if (*p != end)
>     {
>       err = svn_error_create(SVN_ERR_ASN1_LENGTH_MISMATCH, NULL, NULL);
>       return svn_error_create(SVN_ERR_X509_CERT_INVALID_ALG, err, NULL);
>     }

Marc provided more information and I can reproduce the problem by using
the openssl option:

  -sigopt rsa_padding_mode:pss

when signing a server key.  The server cert that is created looks like:

  $ openssl x509 -text -in server-cert.crt
  ...
      Signature Algorithm: rsassaPss
         Hash Algorithm: sha256
         Mask Algorithm: mgf1 with sha256
         Salt Length: 0xDE
         Trailer Field: 0xBC (default)
  ...

I've setup my client to trust the issuer of these server certs but
attempts to access a repository still fail:

  $ svn ls https://...
  Error validating server certificate for '<a href="https://localhost:8887':">https://localhost:8887':
   - The certificate has an unknown error.
  ...
  (R)eject or accept (t)emporarily?

Note the reason for the failure is "unknown error" which corresponds to
SVN_AUTH_SSL_OTHER and SERF_SSL_CERT_UNKNOWN_FAILURE.  I can choose to
temporarily accept and the operation proceeds, but accepting permanently
is not available because that is never offered for SVN_AUTH_SSL_OTHER.

If I try the Java example code tools/examples/ExampleAuthn.java I get a
java exception:

      at org.apache.subversion.javahl.remote.RemoteFactory.open(Native Method)
        at org.apache.subversion.javahl.remote.RemoteFactory.openRemoteSession(RemoteFactory.java:200)
        at ExampleAuthn.main(ExampleAuthn.java:102)
  Caused by: org.apache.subversion.javahl.ClientException: Found invalid algorithm in certificate
  Unexpected ASN1 tag

which is the original problem report.  Our JavaHL code calls
svn_x509_parse_cert() when handling server cert failures, see

  AuthnCallback.c:AuthnCallback::SSLServerCertInfo::SSLServerCertInfo()

and the Java exception is raised when svn_x509_parse_cert() returns an
error.  The command line client only uses svn_x509_parse_cert() in the
"svn auth" command.

If I try to get Firefox to accept the RSASSA-PSS cert it gives me the
error SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED with an explanation:

  The certificate was signed using a signature algorithm that is
  disabled because it is not secure.

but I think that is misleading and RSASSA-PSS is too new rather than
obsolete.  A few months ago OpenSSL gained some RSASSA-PSS support:

  https://github.com/openssl/openssl/pull/4368
  https://github.com/openssl/openssl/issues/2878

The underlying issue is that Subversion/serf/openssl is not able to
validate certs signed with RSASSA-PSS.  The standard client allows the
user to temporarily ignore the problem and proceed, JavaHL doesn't give
the user that option.  If we were to extend svn_x509_parse_cert() to
parse parameters then JavaHL would be able to behave like the command
line client.

In Marc's case getting a new server cert that is not RSASSA-PSS might be
the best solution.

--
Philip
Reply | Threaded
Open this post in threaded view
|

Re: x509 AlgorithmIdentifier parameters

Philip Martin
Philip Martin <[hidden email]> writes:

> In Marc's case getting a new server cert that is not RSASSA-PSS might be
> the best solution.

r1822996 fixes the x509 parser on trunk.  It doesn't mean that the
client will be able to verify the RSASSA-PSS certs (you would need an
OpenSSL fix for that) but it does allow a JavaHL client to accept the
failure to verify.

--
Philip
Reply | Threaded
Open this post in threaded view
|

Re: x509 AlgorithmIdentifier parameters

Philip Martin
Philip Martin <[hidden email]> writes:

> Philip Martin <[hidden email]> writes:
>
>> In Marc's case getting a new server cert that is not RSASSA-PSS might be
>> the best solution.
>
> r1822996 fixes the x509 parser on trunk.  It doesn't mean that the
> client will be able to verify the RSASSA-PSS certs (you would need an
> OpenSSL fix for that) but it does allow a JavaHL client to accept the
> failure to verify.

Another data point: the behaviour varies between openssl 1.0 and openssl
1.1.  With openssl 1.1 the apache server will not even start when using
an RSASSA-PSS cert

  [Sat Feb 03 10:18:03.858279 2018] [ssl:emerg] [pid 2717:tid 139629607192448] SSL Library Error: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak

With openssl 1.0 the server does start.  I'm using openssl 1.1 to
generate the cert in both cases.

A client using openssl 1.0 will connect to a server serving the
RSASSA-PSS cert.  Clients using openssl 1.1 fail to verify cert.  The
underlying openssl 1.1 error appears to be

  $ openssl s_client -connect localhost:8887 -CAfile apache2/ssl/ca-cert.pem
  ...
  Verify return code: 68 (CA signature digest algorithm too weak)

This suggests that RSASSA-PSS is obsolete, but as I mentioned earlier in
the thread there are recent changes to the openssl project
adding/extending RSASSA-PSS support as part of TLS 1.3:

  https://github.com/openssl/openssl/issues/2878

--
Philip
Reply | Threaded
Open this post in threaded view
|

Re: x509 AlgorithmIdentifier parameters

Philip Martin
Philip Martin <[hidden email]> writes:

> A client using openssl 1.0 will connect to a server serving the
> RSASSA-PSS cert.  Clients using openssl 1.1 fail to verify cert.  The
> underlying openssl 1.1 error appears to be
>
>   $ openssl s_client -connect localhost:8887 -CAfile apache2/ssl/ca-cert.pem
>   ...
>   Verify return code: 68 (CA signature digest algorithm too weak)
>
> This suggests that RSASSA-PSS is obsolete, but as I mentioned earlier in
> the thread there are recent changes to the openssl project
> adding/extending RSASSA-PSS support as part of TLS 1.3:

I built openssl trunk (1.1.1-dev) and it is able to verify the cert:

   $ LD_LIBRARY_PATH=/usr/local/openssl/lib /usr/local/openssl/bin/openssl s_client -connect localhost:8887 -CAfile=apache2/ssl/ca-cert.pem
   ...
   Verify return code: 0 (ok)

This is exactly the same server and cert that cause openssl 1.1 to fail.

--
Philip
Reply | Threaded
Open this post in threaded view
|

Re: x509 AlgorithmIdentifier parameters

Thomas Singer (SyntEvo)
Hi Philip,

Thank you for your effort in analyzing this bug and finding work-arounds
or fixes.

We are using a magic script to build all subversion dependencies, e.g.
openssl-1.0.2 and cyrus-sasl-2.1.26. I've used the master branch from
<https://github.com/openssl/openssl> for compiling (~163MB for the
master vs. ~24MB for version 1.0.2) which seems to have compiled fine,
but unfortunately the cyrus-sasl-2.1.26 fails to build. Without actually
understanding what happens there under the hood, I'm a little bit lost.
Should cyrus-sasl also be updated to be compatible with the openssl master?

--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog


On 2018-02-03 22:40, Philip Martin wrote:

> Philip Martin <[hidden email]> writes:
>
>> A client using openssl 1.0 will connect to a server serving the
>> RSASSA-PSS cert.  Clients using openssl 1.1 fail to verify cert.  The
>> underlying openssl 1.1 error appears to be
>>
>>    $ openssl s_client -connect localhost:8887 -CAfile apache2/ssl/ca-cert.pem
>>    ...
>>    Verify return code: 68 (CA signature digest algorithm too weak)
>>
>> This suggests that RSASSA-PSS is obsolete, but as I mentioned earlier in
>> the thread there are recent changes to the openssl project
>> adding/extending RSASSA-PSS support as part of TLS 1.3:
>
> I built openssl trunk (1.1.1-dev) and it is able to verify the cert:
>
>     $ LD_LIBRARY_PATH=/usr/local/openssl/lib /usr/local/openssl/bin/openssl s_client -connect localhost:8887 -CAfile=apache2/ssl/ca-cert.pem
>     ...
>     Verify return code: 0 (ok)
>
> This is exactly the same server and cert that cause openssl 1.1 to fail.
>
Reply | Threaded
Open this post in threaded view
|

Re: x509 AlgorithmIdentifier parameters

Philip Martin
Thomas Singer <[hidden email]> writes:

> Hi Philip,
>
> Thank you for your effort in analyzing this bug and finding
> work-arounds or fixes.
>
> We are using a magic script to build all subversion dependencies,
> e.g. openssl-1.0.2 and cyrus-sasl-2.1.26. I've used the master branch
> from <https://github.com/openssl/openssl> for compiling (~163MB for
> the master vs. ~24MB for version 1.0.2) which seems to have compiled
> fine, but unfortunately the cyrus-sasl-2.1.26 fails to build. Without
> actually understanding what happens there under the hood, I'm a little
> bit lost. Should cyrus-sasl also be updated to be compatible with the
> openssl master?

I would strongly recommend against using OpenSSL 1.1.1-dev for anything
other than testing.

On the systems I have here OpenSSL 1.0 will verify an RSASSA-PSS cert
while OpenSSL 1.1 has introduced a new check that RSASSA-PSS certs fail.
OpenSSL 1.1.1-dev has made extensive changes to the new check and
RSASSA-PSS certs pass once again.

If you want to accept RSASSA-PSS certs then using openssl 1.0 is
probably your best bet.  With patches I posted it is possible to use
openssl 1.1 but only by temporarily accepting the cert on every
connection.  Using openssl 1.0 comes with the caveat that it is possibly
less secure than 1.1 when dealing with certs that are not RSASSA-PSS,
however openssl 1.0 is still widely used.

--
Philip