[ssh_x509] Validating host with certificate chain

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Thu May 18 09:32:09 EEST 2017


Hi Ron,


ssh_x509 at roumenpetrov.info wrote:
> [SNIP]
> Does pkixssh do the other validations mentioned in RFC 6187? In particular, I’m thinking about:
>
>     Additionally, the following constraints apply:
>
>     o  The sender's certificate MUST be the first certificate and the
>        public key conveyed by this certificate MUST be consistent with
>        the public key algorithm being employed to authenticate the
>        sender.
(1s) Server does not validate that "sender's certificate MUST be the 
first certificate". Note dependency from second constraint. Server 
assumes this.
(1c) On load client expect first loaded certificate from key material to 
match private key. This is not related to rfc6187. Control was 
implemented long time ago.

Algorithm is checked. This is not related to RTF6187. It is checked even 
for "plain keys".

>     o  Each following certificate MUST certify the one preceding it.
(1s) On server side - no. I chose non-restrictive model more or less 
based on functionality of cryptographic library .
OpenSSL Verification requested two stores "trusted" and "untrusted": 
root certificate must be in "trusted". root in "untrusted" is ignored. 
Additional certificates from key in rfc6187 format are passed to 
untrusted (dunno why I forgot to pass them).

(2c) On client side: yes since 9.0 chain is build internally, so order 
is correct. In 8.* certificate was send is same order as loaded from file.

>     o  The self-signed certificate specifying the root authority MAY be
>        omitted.  All other intermediate certificates in the chain leading
>        to a root authority MUST be included.
(3c) On client side yes - since 9.0 client sends root certificate and 
all intermediate are included (see 2c).

(3s) Server side is less restrictive : more or less because is not 
required by crypto-backend - openssl build chains internally.

> I did a quick test and it looks like it enforces the first constraint on the server side when first loading the keys, but I’m not sure if it enforces this on the client side.
Process is bidirectional (public key from client to server, host key 
from server to client) and in bot direction processing is same.
I mean that for host keys daemon work according "client" rules above (1c 
2c 3c) . Client behaviour is same as rules 1s, 2s, 3s.
> The second point doesn’t appear to be enforced on either side right now. I tried adding an unrelated cert into the middle of the list of certificates and the server didn’t error out. It sent all 3 certificates to the client, and the client still validated the chain just fine, despite the extra certificate not certifying the one before it, or being certified by the certificate after it.
So in 8.* as client/server sends certificates as they are loaded you 
could insert a lot of unrelated certificates - manual process.
In 9.0 extra certificate from key are loaded into untrusted store and 
along with trusted one are used to build chain . Only certificates from 
chain are send.


> The third point is also not enforced. If I provide only the server certificate and no intermediate CA in the server’s private key file but I add both the intermediate CA and the root CA into the client’s X509 store, the validation succeeds.

So on server(receiver) side I prefer implementation to be less restrictive.


> Also, do you do validation of the OCSP responses included with the certificates?

I prefer do not implement this, i.e. client(sender) does not send and 
server(receiver) ignore OCSP part.
More or less because:
- I prefer to avoid extra complexity in programs
- OCSP validation was implemented long time ago expired from past 
configuration of Mozilla's based browsers.

Lets review option VAType (pkixssh client or server):

(a) none: do not use OCSP to validate certificates;
(b) ocspcert:validate only certificates that specify ‘OCSP Service 
Locator’ URL;
(c) ocspspec:use specified in the configuration ‘OCSP Responder’ to 
validate all certificates.


In the past (c) was allowed to be set in Mozilla's configuration but 
today it is only a check box: checked/unchecked <-> ocspcert/none.


Roumen




More information about the ssh_x509 mailing list