ca cert from client, js fs/os access?

[martijnlammers]

Hi, I currently have a nodejs client making requests to a CCF network. I can make unauthorized requests without a network certificate just fine. Currently in order to make authorized request I'm downloading the net_cert off my server so I can use it on my client.

I was wondering if there is a better way of getting the ca than to download it and whether the JS app has os/fs access once it's in the network?

[eddyashton]

Hi @mAlyanak.

You can retrieve the network cert automatically from the service from the /node/network endpoint, but it's risky to do since it could be spoofed.

$ curl https://127.0.0.1:8000/node/network -k
{"current_view":2,"primary_id":"526abf062494bcc9e7b2c647f71670ea842e14061847c713f8cdfc3d5bf05061","service_certificate":"-----BEGIN CERTIFICATE-----\nMIIBtzCCAT2gAwIBAgIQSOnSCaaOWNnADef1HQ1NkzAKBggqhkjOPQQDAzAWMRQw\nEgYDVQQDDAtDQ0YgTmV0d29yazAeFw0yMTAzMTEwMDAwMDBaFw0yMzA2MTEyMzU5\nNTlaMBYxFDASBgNVBAMMC0NDRiBOZXR3b3JrMHYwEAYHKoZIzj0CAQYFK4EEACID\nYgAENU3Q7mFyqDcDpHR9J1aXxNtExrFPubs+OZqGB3IB5kk0ZzmrV80Kwc9eON4j\ndJ0E/NF/PTqMka4kNHG7G4xi5mQH7CU8ldTFS9496leGnQyqoDAjRLC/926/mI76\nHZqlo1AwTjAMBgNVHRMEBTADAQH/MB0GA1UdDgQWBBSZQ09JyaI5b94hjhH4sFin\nFJHggzAfBgNVHSMEGDAWgBSZQ09JyaI5b94hjhH4sFinFJHggzAKBggqhkjOPQQD\nAwNoADBlAjEA6lgQCvZpIq72fyxbFLy4qh84zlCGK7ofy0J0dREvlffvtJqvV1FF\npOXI4rGIeBI7AjAWFzT7YW4YrgMfu2zV0tx0X8LmvZnM2kHMrDs2H/DTewyy4qQC\niU9fBRIfzGsXHHM=\n-----END CERTIFICATE-----\n","service_status":"Open"}

$ curl https://127.0.0.1:8000/node/network -k | jq -r .service_certificate > ./network_cert.pem
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   815  100   815    0     0  45277      0 --:--:-- --:--:-- --:--:-- 45277

$ cat network_cert.pem 
-----BEGIN CERTIFICATE-----
MIIBtzCCAT2gAwIBAgIQSOnSCaaOWNnADef1HQ1NkzAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDDAtDQ0YgTmV0d29yazAeFw0yMTAzMTEwMDAwMDBaFw0yMzA2MTEyMzU5
NTlaMBYxFDASBgNVBAMMC0NDRiBOZXR3b3JrMHYwEAYHKoZIzj0CAQYFK4EEACID
YgAENU3Q7mFyqDcDpHR9J1aXxNtExrFPubs+OZqGB3IB5kk0ZzmrV80Kwc9eON4j
dJ0E/NF/PTqMka4kNHG7G4xi5mQH7CU8ldTFS9496leGnQyqoDAjRLC/926/mI76
HZqlo1AwTjAMBgNVHRMEBTADAQH/MB0GA1UdDgQWBBSZQ09JyaI5b94hjhH4sFin
FJHggzAfBgNVHSMEGDAWgBSZQ09JyaI5b94hjhH4sFinFJHggzAKBggqhkjOPQQD
AwNoADBlAjEA6lgQCvZpIq72fyxbFLy4qh84zlCGK7ofy0J0dREvlffvtJqvV1FF
pOXI4rGIeBI7AjAWFzT7YW4YrgMfu2zV0tx0X8LmvZnM2kHMrDs2H/DTewyy4qQC
iU9fBRIfzGsXHHM=
-----END CERTIFICATE-----

The -k option to curl is insecure:

 -k, --insecure      Allow insecure server connections when using SSL

This turns off any checking of the server identity, allowing you to make client commands when you don't know the server identity (for instance when the server is brand new, and you want to fetch the network certificate). The problem is that anything which can intercept that curl command (ie - can appear to your client like it is serving on the network address you requested), can serve you its own certificate like this, so if you don't trust the network stack between you and the server, you shouldn't use this cert. In other words, it's an acceptable way of retrieving the network cert when you start up your own service (assuming that curling to this address is similarly trusted to however you'd ssh or similar onto the serving box to download the file), but to distribute that to any other user you should send it to them directly. The idea is that users trust the service transitively because it is endorsed by some members who they trust to govern it safely, and part of that endorsement is the members publishing the identity of the service so that users know how to safely connect to it (where that identity includes both some addresses where it can be reached, and the certificate which only the service can use for TLS handshakes).

For the second part; no, applications running inside CCF (in either JS or C++) do not have direct access to the filesystem or operating system. They are a sandboxed HTTP server running inside an SGX enclave, and their only communication is via HTTP RPCs and storing things on the distributed KV-store. The goal here is that all data which flows into the system comes over protected streams from a verifiable identity, rather than from the untrusted host. So rather than the application code trying to read from the local machine's untrusted file system, it can receive any state it needs over TLS from a member or client. To respond to changes in the KV, other systems should either poll the system or follow the ledger.