Connection not private about astroberry-server

[rkaczorek]

Let me clarify this issue. I included https in the Astroberry Server for users that want to access it remotely over public networks. All you need to do is to replace server certificate with your own commercial certificate bound to a domain you own. For the release I use self-signed CA certificate used to sign server certificate. To build a chain-of trust on local network you need to import CA certificate as a trusted CA in your browser or make an exception by manually trusting server certificate. Neither approach provides full security whatsoever in local network. This is just impossible by design of public key infrastructure, which requires trusted third party. There is no trusted third-party that would sign a certificate for non-public domains, the reason being there is no unique domain name nor IPs in private networks.
I believe it introduced much of confusion among users, especially that browsers' policies are becoming more and more restrictive on this matter, simply disallowing self-signed certificates. To address this issue the next release of Astroberry Server will be accessible over HTTP and I will leave it to users to set up HTTPS on demand, not by default. The same for VPN which is just separate security layer, which can be added to the Astroberry Server on demand. It will not be installed by default for the very same reasons (self-signed certificates, no real chain-of trust, additional actions required on the client side).
Also please note, that the issue does not apply to accessing Astroberry Server over VNC directly.

[jochym]

As far as I know if you run on astroberry.local network new chrome/firefox will not consider the connection private even if you install your own certs. For security to work without any warnings on recent browsers you need to run on the public IP with proper cert chain installed or used (or letsencrypt certs).
In fact it seems correct - it is too easy to spoof private address ranges/certs and they try to avoid false sense of security. But if you have proper https setup and cert the connection is still encrypted.

[rkaczorek]

This is correct. In majority of browsers there's no way to recognize self-signed certificate as trusted, even though you install CA certificate manually. It is the result of change in browsers' security policies.You still can do it in Firefox for Linux by manually accepting exception (tested and confirmed) - I'm not sure about Firefox for Windows. I have received reports that there are problem with chrome on all systems, which does not allow for adding exception by a user. This is up to authors of browsers and cannot be addressed in Astroberry Server directly. For the sake of usability in the upcoming release default configuration will use plain http (https will still be available).

[oprache]

Thank you both. I can run using xrdp so I am set for the time being but would welcome the upcoming release to be able to run using my iPad (VNC does not provide high resolution nor good colors)

[jslight90]

Firefox on Windows seemed to allow successful access to the site after adding an exception for the certificate error.

I have my own private Certificate Authority and was able to generate a new certificate that works fine in all browsers. I believe the issue with your certificate is that the CA cert and Web Server cert share the exact same Common Name. This causes the Subject and Issuer fields of the Web Server cert to be the same which should only occur with self-signed root certificates (the CA cert). When a browser sees this, it tries to verify that the digital signature coincides with the Issuer's public key; in this case, it checks against the Web Server's public key instead of the CA's public key, causing it to fail.

I believe that simply adding something like an OU to the Common Name of the Web Server cert will fix this (requires generating new certificate of course).

With both CA certs installed, Windows itself doesn't like your certificate:

[jochym]

This approach is going to break soon. The browser manufacturers are going in direction of locking down loopholes like this soon. https was simply not designed for this use-case. If you need security use VPN or SSH tunnel. Otherwise you are just fooling yourself with false feeling of security - which is actually worse then knowing that you are insecure.

[jslight90]

For anyone that would like to generate a new certificate of their own (using openssl):
This requires generating a new CA certificate as well since users do not have access to the CA's private key.

1. SSH or VNC into RPi (open a Terminal window if you used VNC)
2. navigate to NoVNC directory

cd /opt/noVNC/

3. rename existing certs

mv astroberry.crt astroberry.crt.old
mv server.pem server.pem.old

4. make a new directory for certificate generation

mkdir ca
cd ca

5. download openssl config file from astroberry.cnf

wget -O astroberry.cnf https://github.com/rkaczorek/astroberry-server/files/2294669/astroberry.cnf.txt

6. create files needed by openssl

touch ./index.txt
echo 'unique_subject = yes' > ./index.txt.attr
echo 01 > ./serial

7. generate certificates

subject='/C=PL/ST=mazowieckie/L=Warsaw/O=Astroberry Server/CN=Astroberry.local'
openssl req -x509 -config astroberry.cnf -newkey rsa:4096 -keyout astroberry.key -out astroberry.crt -subj "$subject TLS CA"
openssl req -new  -config astroberry.cnf -newkey rsa:4096 -keyout server.key     -out server.csr     -subj "$subject"
openssl ca -batch -config astroberry.cnf -keyfile astroberry.key -cert astroberry.crt -in server.csr -out server.crt -notext

8. copy certificates into place

cp astroberry.crt ../
cat server.key server.crt astroberry.crt > ../server.pem

9. restart nginx service

sudo service nginx restart

For security, I highly recommend deleting the entire ca directory created in step 4 (at the very least, the astroberry.key file inside). If you install the CA public key as a trusted CA on your computer, any certificates signed with the CA private key will be trusted by your computer.

The certificate link on the splash page (http://astroberry.local/) should now point to your new CA certificate to install on your computer(s)/phone(s)/etc.

P.S.
If you would like to set up your own Private CA, I recommend setting up a CRL publishing location and using an encrypted Offline Root CA. This will allow you to revoke an Intermediate CA certificate if the private key ever becomes compromised.

[jslight90]

This isn't a loophole, it's how PKI works. Public and Private CAs are exactly the same, the only difference is that Public CA root certificates come pre-installed with your computer/browser. Most CA root certificates are self-signed, some are signed by another CA instead. CAs that are signed by another CA are known as Intermediate CAs; in which case, a certificate chain will be required to link certificates back to the root CA certificate stored on the client computer/browser. You can bypass the requirement by installing the Intermediate CA certificate as a trusted CA directly on the client.

Private CAs are more secure than Public CAs (as long as you protect the root private key properly). Private CAs allow you (instead of a third party) to choose what gets signed and accepted by your computers. Most large corporations typically use a PKI to some extent, especially to use client certificates (not usually provided by public certificate authorities). Client certificates are great for things like trusted device management, data encryption, digital signatures, enterprise WiFi (RADIUS), and smart cards.

About two to three years ago, Public CAs changed their requirement so that domain(s)/IP(s) included in certificate requests must be registered to you/your organization. No one can register private IP addresses (like 192.168.10.1), they are reserved for use on internal LANs. Also, lots of network designers liked to use internal DNS domains (like .local), most of these domains have been allocated as GTLDs now; no one can register a GTLD, they are reserved by IANA for subdomaining. You cannot acquire certificates containing these from a Public CA. Private CAs however, have no such restrictions and can sign any certificate they want, just as you can override your internal DNS for a public domain that you don't control ( facebook.com. IN A 127.0.0.1; *.facebook.com. IN A 127.0.0.1 ).

[jochym]

Yes @jslight90 if you use them the way openvpn uses them with you holding a key to the session on your side. The way https uses them, with dns as a important part of the chain of trust, it is impossible to maintain this chain because everyone can claim any private address. As far as I understand it this makes https virtually useless on the private networks and the actions of browser manufacturers indicate that this is correct. Everyone can, of course do as he pleases. I am just warning: If you need security on private network use technologies designed for such uses: e.g. ssh tunnels or openvpn connections.
BTW: @rkaczorek maybe we can add openvpn manager/server to the system? I am too busy right now to actively help with this but I may be able to make something in 2-3 months.

[jslight90]

it is impossible to maintain this chain because everyone can claim any private address.

Correct, but web-browsers aren't changing anything regarding this, only Public CAs. Mostly unrelated, many browsers have recently stopped accepting self-signed certificates being used directly, require the domain name be listed in the SANs (no more fallback to checking Common Name), and have started using their own trusted certificate store rather than the one your OS provides (this can be changed back easily).

This is the entire point of using PKI. Even though the address may not be unique, only a server that presents a public key signed by a CA your computer trusts will show as valid; they must also have the corresponding private key to decrypt anything you send them. Your computer will not reach out to any external resources to validate the digital signature (it's simply math, albeit complex math); it may reach out to CLR(s) to verify that none of the certificates in the chain have been revoked.

A problem arises if trusted CA(s) issue certificates for the same domain/IP to different people. This would cause all clients, that trust signing the CA(s), to inherently trust both people for that one resource (could be used for MitM attack). Because of this, Public CAs now only allow for domains/IPs that they can verify are registered to you/your organization.

Here is the whitepaper on it: https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf

With a Private CA, you have full control over which certificates you sign and can verify ownership yourself. I could easily generate a certificate for any public domain/IP, point my LAN DNS/routes to an internal server, and spoof the site. Everything would show valid on my computers, but only my computers would trust it because they are the only ones that trust the CA that signed the certificate.

The only improvement I can think of would be to have the Astroberry Server automatically generate it's own cert chain, so that each user would have his/her own unique Private CA and keep the root private key secure (best to just delete it if you don't plan on reusing it). You could even allow users to enter their own additional domain names to be added as SANs (this is perfectly okay because this isn't a Public CA).

tl;dr
Public and Private CAs have different restrictions when signing certs; browsers don't know/care which type of CA is used.

[rkaczorek]

Fixed in version 1.1.0