Re: x509 AlgorithmIdentifier parameters

[Thomas Singer]

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 
 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  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.

Re: x509 AlgorithmIdentifier parameters

[Philip Martin]

Philip Martin  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

Re: x509 AlgorithmIdentifier parameters

[Philip Martin]

Philip Martin  writes:

> Philip Martin  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

Re: x509 AlgorithmIdentifier parameters

[Philip Martin]

Philip Martin  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

Re: x509 AlgorithmIdentifier parameters

[Philip Martin]

Philip Martin  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, , 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 '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